That's a pretty weak motivation. While the RFC saves characters, one should be very careful about adding one-off syntax changes like this.
That quote was from a tiny note about using
.into() instead of
Some(), so that's taken out of context quite a bit. And while it's true that this RFC does save characters, that's not the only motivation listed.
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.
Potentially, something that could go into the future section, though I don't think it aligns with this particularly, since it's all a special case for structs.
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.
Not necessarily. I think this deserves its own syntax, given how complex some structs can be, especially if it would mean people could port the builder pattern afterwards.
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.
I don't think this is a valid argument at all, similar to saying "why explore space when we have problems here on earth"? Yes, there are some problems in the compiler, and const generics are needed, but that shouldn't mean not adding new features, e.g the
try block, which is (mostly) equivalent to an immediately invoked closure. But, calling it try is much nicer, signifies intent clearer, and does in fact save characters.
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.
syn , all (!!!) procedural macros, etc.) don't have to update their syntax and AST support code with yet another case.
There's no reasonable way a macro could figure out if a field was flagged optional or not, any implementation of such a macro would be rather buggy.