Confusion about line in restrictions RFC

help
1

I have sometimes wanted to have read-only fields in Rust, so I was glad to learn about the accepted restrictions RFC. It isn't my favorite syntax for the feature[1], but they all have different flaws. However, one line in the alternatives section of the RFC book entry was confusing to me:

some positions such as enum variants do not semantically accept a visibility, while they do accept a restriction

This didn't make much sense to me, since a mut restriction does not seem useful on enum variants, or at least much less useful than a visibility. Additionally, the future possibilities section of the same entry suggests as a future possibility:

mut could be placed on the struct or variant itself, which would be equivalent to having the same restriction on each field

While I can understand that adding visibilities to enum variants might be much more difficult than adding mut restrictions (because of pub currently being implicit on all enum variants), enum variant members getting visibility seems much more useful than getting mut restrictions, and there's no semantic reason why enum variant members couldn't accept a visibility, as far as I can tell, other than that they don't currently.

So, what does the RFC mean when it talks about mut restrictions being used in places where visibilities are not semantically allowed?

  1. My favorite syntax is similar to the syntax described in this issue comment, with two changes: I'd want ref in … to indicate where a field can be referenced (rather than that being indicated just by the path), and that I think that the commas should either be replaced with semicolons or use in * for everywhere (this becomes helpful because of pub(ref, mut in crate being confusing). To give a specific example of one benefit mentioned in the comment ("It's more scalable") which I don't think has been pointed out elsewhere, I think that this syntax would be a good fit for unsafe fields, like so:

    struct Example {
    pub(
        unsafe mut in *,
        ref in crate,
        mut in self, // ideally `in mod` would work too
    ) scary_pointer: *mut (),
}
    ↩︎
2

The way I read it is that the RFC is already doing two distinct things (sealed traits and read-only fields), and tackling private variants would be a third. Probably it just wasn't what they were focused on.[1]

I think they just mean that today, you can't have a pub on an enum variant. (It is actually syntactically valid though.)

  1. Personally I think it should have been two RFCs already. ↩︎

3

Author of the RFC here! Confirming that this is correct. Tackling enum variant visibility is a very different thing than was proposed here, which is effectively sealed traits and read-only fields (just a bit more flexible for both). I had offered to split it into multiple RFCs if anyone on the team wanted it, but this was never requested.

I have been working on rebasing the PR that implements the feature in its entirety (behind separate feature flags). You'll be able to play around with this on nightly relatively soon.

1 Like