given that the omitted fields all themselves implement Default even though the parent struct doesn't? I found some prior discussion on the documentation surrounding this, but didn't see much about what it would take to actually support it. Is there prior art here?
Hm, that RFC is interesting but I think it addresses a different use case here. The one I'm talking about is where a struct can't be Default because some of its fields need values known only at runtime (so they can't be set in the struct declaration itself), but where most of its fields areDefault and could be omitted for their redundancy. Adding default field values is certainly handy, but only useful for compile-time values. I've seen this come up at times in builder patterns for example.
EDIT: The Zulip chat gets closer to what I mean here, though that still requires Default for the initialization. In this sense I think the spirit of the FRU syntax isn't necessarily wrong if it actually could be what it looks like in terms of being a fold/spread operation over the unmentioned/omitted fields.
The RFC allows that! You can specify the defaults for everything that can be set in the declaration, then when you use the literal you have to set those fields without defaults, but can still , .. } to get all the other defaults.
Unless you mean that they're Default but not const Default?
When implementing Default for a large struct when only 1 field has something that can't be derived, others must be field_x: Default::default(). You can't use .. Default:: default(), because you are implementing it...
In this case I was asking if this limitation (it can result in a lot of redundant Default::default() lines) has been discussed before, and it looks like RFC 3681 does plan to provide an improvement on the ergonomics here. So, problem solved!