|
| 1 | +# Meeting 1: 13 Sept 2018 |
| 2 | + |
| 3 | +The active discussion is still Data Representation. It seems like we’re ready for writeups for the following issues: |
| 4 | + |
| 5 | +- [structs](https://github.com/rust-rfcs/unsafe-code-guidelines/issues/11) and [tuples](https://github.com/rust-rfcs/unsafe-code-guidelines/issues/12): niko |
| 6 | +- [references and pointers](http://16https://github.com/rust-rfcs/unsafe-code-guidelines/issues/16): avadacatavra |
| 7 | +- [function pointers](https://github.com/rust-rfcs/unsafe-code-guidelines/issues/14): nicole mazzuca |
| 8 | +- [packed/align](https://github.com/rust-rfcs/unsafe-code-guidelines/issues/17): **<this could be you!>** |
| 9 | + |
| 10 | +We’re still looking for a consensus/further discussion on: |
| 11 | + |
| 12 | +- [enums](https://github.com/rust-rfcs/unsafe-code-guidelines/issues/10) |
| 13 | +- [unions](https://github.com/rust-rfcs/unsafe-code-guidelines/issues/13) |
| 14 | +- [integers/floating points](https://github.com/rust-rfcs/unsafe-code-guidelines/issues/9) |
| 15 | + |
| 16 | +If you’re interested in working on a writeup, please comment on the issue. I’ll be adding some tags to help us organize this. See zulip for the [full log](https://rust-lang.zulipchat.com/#narrow/stream/136281-wg-unsafe-code-guidelines/topic/meeting.202018-09-13). |
| 17 | + |
| 18 | +##How is the format working out? |
| 19 | +Overall, it seems like the github discussions are productive. However, there’s the question of how we produce concrete summaries/writeups/more permanent artifacts (aka how are we actually writing this reference book?). |
| 20 | + |
| 21 | +**Who/what/why/when/how of writeups** |
| 22 | +We should designate people responsible for writeups earlier. This is also a place where we should reach out to members of the community who might be interested/involved in topics elsewhere, but not necessarily aware of the discussions occurring here. |
| 23 | + |
| 24 | +The writeups should reflect whatever consensus was reached in the GH issue—someone will summarize the discussion and open a PR on the mdbook in the repo. We can then iterate on the PR with comments/reviews/suggestions. If needed, we can always merge a starting point PR (for documentation and revisitation) or close a PR if it looks like the topic needs more discussion. |
| 25 | + |
| 26 | +So, what do I mean by **consensus**? We don’t need to agree on what the answer is, but we should agree on what the questions are. Some things to think about: |
| 27 | + |
| 28 | +- how is this topic currently handled? is this appropriate? |
| 29 | +- what are different approaches and tradeoffs? |
| 30 | +- what do people need to keep in mind when dealing with this topic? |
| 31 | +- if there isn’t necessarily a right way, is there a wrong way? |
| 32 | + |
| 33 | +We’ll see how this writeup process goes and document it once something seems like it works. |
| 34 | + |
| 35 | +##What’s next? |
| 36 | + |
| 37 | +- Oops! We forgot to add a [license](https://github.com/rust-rfcs/unsafe-code-guidelines/issues/20). |
| 38 | +- Start writing up the Data Representation chapter |
| 39 | + - Do we want to say anything about other representations (e.g. `Box`, slices, fat pointers…) |
| 40 | + - Should we have an ABI section |
| 41 | +- Keep discussing topics that aren’t ready for writeups |
| 42 | +- Figure out how to do writeups more effectively |
| 43 | + |
0 commit comments