That's a pretty weak motivation. While the RFC saves characters, one should be very careful about adding one-off syntax changes like this.
For one, shortness doesn't necessarily help reading. (Ease of reading the code is far more important than writing convenience – code is read a lot more than it is written.) In this case, I find the proposed syntax harder to read than Option
. Rust already has a proliferation of symbols, I'm glad at least most types don't hide behind sigils (well, except pointers and references, which are builtins, unlike Option
). Adding yet another overload for the meaning of ?
would be a mistake.
Second, the proposal doesn't carry its weight when put in the context of other parts of the language, either. Why just struct fields? Option can be used in any place where a type is expected. To me, this just signals that the idea is not really fleshed out, and it's not considerate nearly enough with regards to its impact on and interaction with everything else.
Finally, there's also the question of priority. There far more important things in Rust development to worry about. The compiler wants its soundness bugs fixed, const generics and variadic generics are desperately needed, specialization has a fair number of unresolved correctness questions, the list goes on. It is especially ill-advised to push for superficial changes like this when the design, implementation, and testing of far more substantial features still somewhat lacks sufficient human resources.
If you want a syntax tweak, just use a macro. That's exactly what macros are for. You can write a procedural macro that transforms the proposed code into the currently-accepted style. It's better for you too, because you don't have to wait for it. And it's better for the community, because tools and libraries that operate over Rust syntax (e.g. rustfmt
, syn
, all (!!!) procedural macros, etc.) don't have to update their syntax and AST support code with yet another case.
There are countless syntax changes that one could reasonably propose. The question is always "why?" and not "why not?" – if all of these changes would be accepted and implemented, the developers would do nothing else other than changing the parser all the time. I'd therefore argue that whatever syntax can reasonably be implemented as a macro should in fact be a macro and not a core language change.