That’s not what I was getting at. Assume all of those (including the ones specified) had defaults. You’d have to “skip” all the defaultable arguments you didn’t want to specify to get to the ones you do. I’m saying that without named arguments, that’s kinda sucky.
1 Like
I would vote -0 on this. It sounds nice, but rarely enough useful to be worth new syntax. I find myself almost only using struct literal expression in constructors.
3 Likes
That would be exciting to have.
This reminds me of glium’s draw-parameters construction; whatever is left out becomes a default value. I don’t know the code behind it, but it’s nice to use. @tomaka can perhaps explain more
eg:
let params = glium::DrawParameters {
depth: glium::Depth {
test: glium::DepthTest::IfLess,
write: true,
.. Default::default()
},
.. Default::default()
};
I would definitely use it, particularly for structs with Option<> fields that will default to None. Currently I find constructors can end up being unnecessarily big… maybe my structs are too big
Seems like this would be something to propose in tandem with some solution for defaulted arguments in fns.
1 Like
I really hope rust gains this feature aswell. It would be good to experimentally implement alongside function argument defaults, I looked at doing latter but didn’t get so far, but I saw there’d be a common pattern between the two.
How far could either of these go, could the defaults be expressions rather than just values, with some restriction on dependancy (e.g. each expression can only depend on earlier values).
I wonder if the core team would be open to parsing them into the AST but not actually use them (spit out an error message when found), just to make experiments on this feature easier. (without peoples experimental forks diverging too far).
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.