Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
RFC for a match based surface syntax to get pointer-to-field #2666
Extend match syntax (
This should be read as complementary surface syntax to the MIR changes proposed in #2582 . Now, somewhat coincidentally, the author @RalfJung decided to rewrite the other PR to also include a surface syntax. I was unaware of this parallel process . If desired, one could read the match/pattern syntax as complementary to the place expressions proposed there but since the idea was floating around for a while, I address the downsides in comparison to match in
I can see good arguments for having pattern syntax on top of explicit pointer-taking syntax, just like we do for references. However, it would be rather strange IMO to have only pattern syntax and not also a direct way to express this -- that would be very inconsistent with the handling of references. I also think that would hurt teachability, as you'd have no more direct way to express what happens in these patterns.
Pattern matching is already hugely complicated with guards and their evaluation order concerns, implicit derefs, handling of empty types, and so on. It is arguably the most complex language construct, and in fact it is the main reason why I pretty much refuse to do anything formal about surface Rust or the HIR -- I prefer working on the MIR where pattern matching has been almost entirely lowered away. At least most of the things it does can be explained as being equivalent to other language constructs: everything except for actually determining the discriminant of an enum. This RFC would add "create raw pointers" as the second such match-only operation. I do not think that is a good idea.
In that light I find myself disagreeing with the arguments in the "Rationale and alternatives" section:
There is nothing new about this, we already do not do auto-deref for raw pointers. The custom code entry points you mention all have to do with using, not creating pointers. Adding a new way to create (raw) pointers (not subject to auto-deref) does not interact with them in any interesting way, from what I can tell.
Also, we do not auto-deref for raw pointers in
Do you have examples for what you are worried about here?
This is an argument for a
You can totally use
Or maybe I am misunderstanding what your point is here. An example would help.
Maybe it should be pointed out specifically that it works for irrefutable bindings perfectly fine, and both pattern
Edit: I've updated the introductory example to make use of this and explained its validity in the reference level section.
Also in light of
¹ Short summary for the problems with pointer-from-place in expressions: In match, references are matched by reference patterns, and optionally inferred, for which they use the type sigils. The operation of creating one has a single purpose pattern with a contextual keyword. In expressions however, the type sigil for pointers is already in use for dereferencing but the reference sigil is reuse for reference taking. Also, since the reference wraps the place expression, safety and ergonomic concerns must be balanced when considering if the place expression must be valid regardless of such a wrapping, as taking out the place-subexpression results in stricter requirements on the validity of the involved memory than when it occurs inside an imagined raw-ptr-expression.