Hacker News new | ask | show | jobs
by estebank 703 days ago
Adding support for struct default field values would allow for

- leaving some mandatory fields

- reduce the need for the builder pattern

- enable the above to be written as f(S { hours: 2, seconds: 53, .. })

If that feature ever lands, coupled with structural/anonymous structs or struct literal inference, you're getting everything you'd want from named arguments without any of the foot guns.
1 comments
kibwen 703 days ago
Has anyone ever proposed it? It's such a straightforward feature with such obvious semantics ("default field values are const contexts") and impossible-to-bikeshed syntax (`a: i32 = 42`) that I've been meaning to write up an RFC myself for around, oh, ten years now...
link
steveklabnik 703 days ago
nrc was poking at the problem in 2016 https://internals.rust-lang.org/t/struct-field-defaults/3412 which led to this RFC https://github.com/rust-lang/rfcs/pull/1806

It got postponed because it wasn't going to make it into Rust 2018: https://github.com/rust-lang/rfcs/pull/1806#issuecomment-327...

link
estebank 702 days ago
Last time I had this conversation[1] the main sticking point were around semantics of private fields, but I am convinced that the maximally restrictive version can be done (only pub fields can be optional) and maybe relaxed later after we get some real world experience. The other thing was about whether the default values needed to be const, but that makes sense as a restriction to me.

1: https://internals.rust-lang.org/t/pre-pre-rfc-syntactic-suga...

link
steveklabnik 702 days ago
Yeah makes sense! I haven’t felt the need for this feature personally, but it feels like it fits with the language pretty well to me. The big issue with default values (as far as I’m concerned) is for them to always have a default value, and this doesn’t change the opt-in nature of the concept.
link
estebank 702 days ago
The issue I have with Default is that the verbosity jump from derive(Default) to impl Default for Type is high, evej if you just want to specify a single field. The other reason I want this is because it makes defining builders almost trivial for any case where custom logic isn't needed for the fields. I would expect the impl-based builder pattern to become more niche if we had this feature. Your reason is yet another that would be nice to address as well. I like how this one change addresses multiple things at once.
link
steveklabnik 702 days ago
Yeah, full agreement here. I almost said something along the lines of "it's almost like extending #[derive(Default)] with serde-like attributes to control which fields get what defaults, but with nicer syntax," but got a little lazy with it since we're in agreement anyway. It is annoying that deriving Default is all or nothing.

I didn't even think about the builder thing, but you're right there too.

link