Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Status of Unsafe Code Guidelines Reference #254

Open
cdisselkoen opened this issue Nov 2, 2020 · 3 comments
Open

Status of Unsafe Code Guidelines Reference #254

cdisselkoen opened this issue Nov 2, 2020 · 3 comments

Comments

@cdisselkoen
Copy link

The README in this repository currently states:

The main goal for the WG in 2019 is to RFC parts of the guide into the language specification, and move those parts into the Rust Language Reference proper.

Similar language appears in the introduction to the Reference itself.

I'm curious about what progress has been made on this (it's now November 2020 at time of this writing). Should we just update this statement by changing "2019" to "2020" or "2021", or are there other updates to mention?

@cdisselkoen
Copy link
Author

(Also please know that I'm not trying to be facetious with this if the answer is just that progress has been slow or gone a different direction. I'm genuinely curious about this project!)

@digama0
Copy link

digama0 commented Nov 2, 2020

There was some recent discussion about this on Zulip. I think the current status is that progress is stalled, but we also have way too much for an RFC at this point so likely next steps would involve separating out chunks that we can bring to t-lang to start the stabilization process. I think lack of decision making power has also been a contributing factor; we all have elaborate theories but none of it is official and the larger the disconnect the harder it is to progress. (In other words, we've been "brainstorming" for two years and forgot what comes next.)

@RalfJung
Copy link
Member

RalfJung commented Nov 3, 2020

A discussion has been had with T-Lang about an RFC for layout guarantees at some point, and T-Lang asked that the documentation we gathered be supplemented with more motivation. But that never happened, the first thrust was already lost at that point and summarizing all the "why" spread across the many issues that lead to the current UCG document does not seem exciting enough that anyone stepped forward so far to do this.^^ I think it would take someone with an actual interest in getting more layout guarantees (I personally have few stakes in this particular discussion) to do that work.

We also started discussion about validity guarantees, but I don't think we were able to reach consensus on any of the types where there were open questions to begin with (mainly: #71, #77). We did learn quite a few new things and my own opinions solidified somewhat (and not always to what I started out as considering the best option), but reaching consensus on these things is hard as there are few objective guiding principles. Furthermore, reference validity is somewhat entangled with the aliasing model, which is a very hard thing to even specify precisely, let alone discuss -- I'd like to specify validity rules for reference that consider only their bit-level properties and their type (but not whatever the state of memory is), but this does not actually help unsafe code authors much as they need to additionally ensure that aliasing rules are respected. So what good would it even do to RFC that "any non-null well-aligned pointer is valid at reference type (where uninhabited pointee types make 'infinite alignment requirements', so no reference is valid)"? Some aliasing model questions might end up requiring some form of "references point to valid data" despite this rather lax validity requirement!

The main purpose of this project right now is to be a central place for people to discuss questions around the "tricky parts" of the Rust semantics, and to have an issue tracker dedicated only to those problems (that would otherwise drown in the main Rust issue tracker).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants