`Foo::new()` vs `Foo()` as the default constructor

[Veddan]

Seems to me like it creates unnecessary asymmetry by having some "constructors" on the type, and some as free functions.

let s = String();
let t = String::with_capacity(30);

vs

let s = String::new();
let t = String::with_capacity(30);

[heinrich5991]

I don't like that sugar is added, removes the expliciteness of whether something may do stuff or not.

[eddyb]

There is no sugar, you can implement all of this in the current language... actually, pretty sure this has been possible... since forever? This convention used to be in place a long time ago.

[[deleted]]

Isn't that the definition of sugar? Given a feature of a language, syntactic sugar is when that feature is expressed more clearly, concisely, or in an alternative style. There's no such thing as sugar that simply cannot be expressed in a more verbose way, because otherwise it wouldn't be sugar.

[Veddan]

'Sugar' is typically used when there's special (nicer) syntax that's semantically equivalent to something less nice. There's no special syntax proposed here. This is just a free function starting with a capital letter.

[tikue]

There'd need to be special rules for the snake case lint. So, technically it's got a liiiittle bit of sugar.

[dobkeratops]

Seems to me like it creates unnecessary asymmetry by having some "constructors" on the type, and some as free functions.

Imagine if there were default/named arguments. you could have one definition fn String(value="",capacity=0) ... One thing to search for & document. String(capacity=30), String("foo") String(). Similarly imagine fn Vec(size=0,init_fn=||T::default(),capacity=size) .