Pre-RFC: Optional FIelds

I think my first instinct here is that I'd like to see ekuber's RFC for = None in struct definitions before considering this.

They're touching enough of the same areas that I'm not sure it'd be worth doing the specific sugar here until we have experience with how that RFC changes the way people write code.

That said, I'll propose this meta-question for you: What is it about Option and Some that make you think it worth doing specifically this conversion in the struct literal?

(And a preemptive plea to those who reply to this: please be more specific than just "explicit is better". Remember the reasoning footprint.)

And some ideas for follow-ups: Are there other cases where it would also be appropriate? Is it equally useful for literals as for variables? Are there other types where it would make sense? ekuber's RFC has an example of .to_string()ing some things in the initializer. Is that a good conversion? Would it be reasonable to say that everything gets .to_owned()ed in a struct literal? Or .into()ed (which would cover Some-wrapping)? There are often parallels between Some and Ok; would it make sense to auto-Ok-wrap values put into a Result field?

2 Likes