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

[bfops]

Something I really like about Rust is that it doesn’t add new syntactic sugar for every little thing, so I’m personally a big fan of Foo::new being just another function. Less special syntax to learn, and fewer cases in my mental parser. Fewer edge cases, too - as others have mentioned, having a few different constructors with explicit names isn’t uncommon, and I’d prefer them all to look similar for the writer and the reader.

[nrc]

I prefer the look of Foo(), but I am persuaded by the argument that ‘constructor-looking’ things should be destructurable in pattern matching, so on balance I prefer Foo::new()

[pythonesque]

I really don’t understand why we keep trying to add more and more syntactic sugar for things. Can we at least wait until 1.0 before we make backwards-incompatible changes to save a couple of characters which don’t actually add additional power to the language?

[nikomatsakis]

On Thu, Nov 06, 2014 at 07:52:03PM +0000, Ben Foppa wrote:

[nikomatsakis]

On Thu, Nov 06, 2014 at 08:36:17PM +0000, Pythonesque wrote:

[bfops]

@nikomatsakis your replies were eaten! Mind re-sending?

[nikomatsakis]

Argh. I always forget that Discourse requires top-posting. All I was saying is that the original proposal involved no syntactic sugar.

[pythonesque]

How are namespace conflicts handled, then? You often do want to use static methods on types other than the original constructor; would you have to use an alias and keep the function in its own module? Is that really simpler or easier, or am I missing a way in current Rust that this would be clean to resolve?

[kennytm]

Under this proposal, how will this code work?

struct Foo(pub uint);

impl Foo {
    fn new(n: uint) -> Foo {
        Foo(1 << n)      // <-- ?
    }
}

let foo = Foo(8);     // <-- ?

[P1start]

This proposal doesn’t alter any language semantics, just conventions. So that example will operate in exactly the same way that it does today.

There appears to be a lot of confusion along these lines, so I’d like to clarify how I understand this proposal with an example. The current convention for the ‘main’ constructor function of a type is to define a static new method on it:

struct Foo {
    x: int,
}

impl Foo {
    fn new(x: int) -> Foo {
        Foo {
            x: x,
        }
    }
}

Under this proposal, the convention will be changed to defining a method in the same scope with the same name as the type:

struct Foo {
    x: int,
}

fn Foo(x: int) -> Foo {
    Foo {
        x: x,
    }
}

This is doable today, and is in fact used in some places (particularly in rustc itself, where conventions are somewhat ignored); for example, syntax::ptr::P uses this convention.

[kennytm]

In that case a tuple-like struct cannot have such “constructors”.

struct Foo(uint, uint);
fn Foo(n: uint) -> Foo { // ← error: duplicate definition of value `Foo`
     Foo(n, 1 << n)
}

[nikomatsakis]

True, my view is that a tuple-struct already has a default constructor, and if you want a different one, you should either use a struct with field-names.

[dhardy]

It annoys me that constructors in C++ don’t have easily searchable names (since obviously the class name gets used many times), besides which it isn’t obvious in a few cases that the constructor is being called. Typing a few extra letters to make that explicit with consistent notation is definitely worth it in my opinion.

[dobkeratops]

Far, Far prefer this. it’s fine to have named functions for ‘alternative’/‘special case’/‘complex’ constructors, but I’ve always found ::new() to be redundant, unnecessary ugliness that stabs me in the eye. I used tuple-structs for vector maths purely because I dislike the idiomatic Vec3::new(x,y,z) convention. This proposed convention would allow you to move back & forth more easily. This is the kind of pointless refactoring issue we’re trying to escape from C++. “if you reverse this choice later, you have to change calling conventions …”

You can currently write struct Foo{} fn Foo()->Foo{} , and it is unambiguous both at call & definition site, hence still easy to search for. (grep struct Foo{ vs struct Foo( vs fn Foo vs Foo( vs Foo{ )

Don’t “Throw out the baby with the bathwater” when comparing to C++: C++‘s system is difficult because of many combined factors: header files, everything is overloaded, there are hidden conversions, and its hard to distinguish a definition from a use in a single line. Rusts’ lack of headers & simpler grammar (especially introducing types with “:” ) cut through many problems.

box Foo::new() also looks very redundant.

its’ also repurposing of the word ‘new’ compared to other languages which might cause confusion for people creating cross-langauge C wrappers.would people expect extern “C” Foo_new() to really be a function that allocates and initialises, returning Foo* ? opposite is Foo_delete(Foo*) ? Rust doesn’t exist in isolation.

Are there any details in language support, for example does use foo::Bar get all symbols ‘Bar’ from foo (both the struct and the fn,if you make one)

[bfops]

I totally misunderstood the original proposal. If it’s just about conventions, then my answer would be to not default to either, but to just choose whichever makes sense for your actual struct (or something else entirely)… For little things like Vec3, I’d definitely agree this seems nicer.

[Manishearth]

This makes it clash with tuple struct constructors though. I prefer Foo::new() for user defined constructors, and Foo() for compiler provided tuple-like construction for variants/tuple structs.

[nwin]

I would strongly vote for consistency. As bstrie already wrote: Why should ::new be special compared to ::with_capacity?

Reminder: If this change comes, it also has to be ensured that &Foo returns a function pointer as &Foo::new does

[Jurily]

My main problem is that it breaks the style. I don’t really like Rust’s default style, but at least it’s consistent.

I could live with Foo::foo() or non-method foo().

[bjadamson]

::new() is a huge improvement in consistency then introducing the idea of constructors. -1

[ruudva]

Type::new() is one of the things that I immediately liked about Rust. It shows that the constructor is not special or magical in any way; it is just a function. Of course, when the constructor is a free function this is still the case, but this is not immediately obvious, especially for people coming from C++/C#/Java, where the constructor is special. If Vec() would be the default constructor for Vec, then it could also be confusing that Vec::with_capacity(c) is a constructor as well. It might be more consistent with tuple structs and enum variants, but it is less consistent with non-default constructors.

The five extra characters do not bother me at all. Rust is already quite concise (e.g. Rc instead of C++’s shared_ptr).