Struct field defaults

[DanielKeep]

Unlike struct literals, function invocation doesn’t have a syntax for “skipping” arguments. Which is to say: it’d be kinda sucky to have defaultable arguments but not named argument syntax. I suppose you could use _ but that’s icky: foo(_, _, "dingbat", _, Cheeseburger, _, _, _, -8) (pedanting about functions with too many arguments aside).

[WiSaGaN]

I would say it’s explicitness.

[leonardo]

Every design decision needs to consider its costs and balance them. Not having default arguments and function overloads forces your API to be larger, because you need more functions with a different number of arguments. And this sometimes causes problems:

Enumerate a vector of results

In that case format() is “taken” because you can’t change the function later to make the second argument optional. So the API is worse, you have a longer named function (format_default) to replace a simpler function (the one with just one argument).

[petrochenkov]

I use this feature often in D language.

I can say the same about C++.
I’d also appreciate default function arguments.

[WiSaGaN]

I am sure there are use cases where these features will help you type fewer keys when you first code your program. Whether they are justifiable to be added is another issue. Apart from the potential feature bloat problem, having the default spelled out usually helps in the domain Rust is supposed to be used in. These domains include OS/drivers, infrastructures, game engines. Unlike web programming or scripts, code in these domain tend to be read a lot more than be written. Code is also less likely to change in these areas, thus typed again. I don’t seen much benefit in saving a few keytypes. Overloads, ad-hoc defaults (not Default trait) add mental load to code readers and maintainers, and sometimes become source of bug. I have seen a lot of surprising, implicit defaults caused bugs introduced in our production code in C++. Various guidelines are formed just to forbid these kind of features in C++, and I think this is not uncommon in the industry. Coming from C++, I certainly hope Rust would not have the same number of features C++ has. I worry that even if we just slowly add features like this Rust will have just too many features even before becoming mainstream like C++.

[leonardo]

Various guidelines are formed just to forbid these kind of features in C++,

What guidelines say that default values for struct fiends are bad?

[WiSaGaN]

Internal guidelines. Similarly, config files are required to spell out values explicitly unless there are really natural, unsurprising defaults. Apology if this seems away from topic.

I’m not against default values in fields completely, just thinking it should be limited. I am perfectly fine with using .. to indicate fields that should take the value of Default::default(), since when we implement Default for a type, the value is usually natural and does not surprise anyone, such as 0 for u32, None for Option<Value>. But using .. to denote an i32 takes -1 worries me, and I would like to have it explicitly spelled out even at the call site in most cases so that reader would not get a false impression. If this default value is indeed appreciated, then maybe an explicit constructor that takes only other fields, or using associate constants can help.

[kevincox]

I would use this all the time.

[GolDDranks]

Although already noted elsewhere, I want to bring up here too, that the Default trait builds and returns a whole struct and if another struct’s default values are taken from that, you might need some compiler optimization to not do any needless work (to not initialize and drop fields that are not even used in the resulting struct). I’m not even sure if optimizing everything away is possible in the general case, because calling default() might have side effects.

I’d appreciate if someone with greater knowledge would chime in and verify if this is a thing that affects performance, or am I worrying for nothing?

[yigal100]

That’s why the rule in C++ requires that all the defaulted function parameters will be after the non-defaulted ones.

[OZ_]

I wonder why we don’t have so obvious thing from the beginning

[DanielKeep]

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.

[SimonSapin]

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.

[sargas]

That would be exciting to have.

[viperscape]

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()
                };

DrawParameters

[stevenpack]

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

[nikomatsakis]

Seems like this would be something to propose in tandem with some solution for defaulted arguments in fns.

[dobkeratops]

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).

[leodasvacas]

This should now be discussed in this RFC which proposes this feature.

[nrc]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.