Allow C++ like syntax for variable declaration and initialisation via constructor

[surfsquid]

I think it would be cool to declare and initialise variables neatly like in C++
Like:
Person person("Matt", "Smith");

I've just started using C++ and I really like this syntax, would it work in the C# world though?

[YairHalberstadt]

What advantage does it provide over current (as of C# 8):

Person person = new("Matt", "Smith");

?

[surfsquid]

Less typing (= new) apart from that, not much! I think it looks a little cleaner, personally.

[mrtaikandi]

I think a better example of its usage would be something like this:

var matt = Person("Matt", "Smith")

or

var persons = List 
{
    Person("Matt", "Smith"),
    ...
}

[ufcpp]

#350

[ygc369]

I think that C# struct should use C++ style of constructor, while C# class constructor should keep unchanged.
Because C# syntax for struct variable declaration and initialisation via constructor (using "=") seems to cause an unnecessary copy (allocate a temporary struct and then copy it to the right place). Of course, Microsoft C# compiler or JIT might optimize this and omit the unnecessary copy, but it seems that there's no guarantee that all 3rd-party C# compilers must implement this optimization. Even if all C# compilers could do this optimization, the syntax itself would still puzzle inexperienced programmers and make them worry about unnecessary copy.
If C# struct variable could use C++ syntax for declaration and initialisation, then it would be very clear that the struct variable could be initialized in place. Thus nobody would worry about unnecessary copy.

[HaloFour]

@ygc369

Because C# syntax for struct variable declaration and initialisation via constructor (using "=") seems to cause an unnecessary copy

Except that it doesn't. The struct is always initialized in place on the stack by loading the address of the local slot and invoking the struct constructor. Not only has this always been the way that C# has behaved but C# doesn't need a second redundant syntax just for the sake of comforting those few developers who would be worrying about how and when value types are copied but aren't willing to read the documentation about it.

[YairHalberstadt]

@HaloFour
I'm not sure you're correct: https://ericlippert.com/2010/10/11/debunking-another-myth-about-value-types/

[HaloFour]

@YairHalberstadt

Foo foo = new Foo(1, 2, 3);

turns into:

        IL_0001: ldloca.s 0
        IL_0003: ldc.i4.1
        IL_0004: ldc.i4.2
        IL_0005: ldc.i4.3
        IL_0006: call instance void Foo::.ctor(int32, int32, int32)

There is no copy. The struct is initialized in place onto the address of the local slot.

[YairHalberstadt]

@HaloFour
That's an optimisation, but the spec requires a copy. See the article I linked

[ygc369]

@HaloFour
I know that Microsoft C# compiler has this optimization. But can you guarantee that all 3rd-party C# compilers have this optimization? I think you can't.

[YairHalberstadt]

@ygc369
Do you know of any up to date C# compiler other than Roslyn?
They don't exist, so that point is irrelevant.

[ygc369]

@YairHalberstadt
Mono

[YairHalberstadt]

That still doesn't have full support for C# 7. The earliest this change would occur is C# 9.
I think it would be a lot easier to make sure Mono has this optimisation than to add a new language feature.

[YairHalberstadt]

The last change to MCS (the mono compiler) was last december. I really don't think it's going to keep up with new C# features. Besides it currently makes no optimizations at all - anyone who cares about performance will not be using it. Adding a language feature just so that MCS will have an absolutely tiny performance gain when you use it, is totally pointless.

[HaloFour]

@YairHalberstadt @ygc369

This isn't an optimization. This is a requirement per the CLI spec. A struct constructor is required to accept a first ref T parameter into which that constructor will initialize the struct. The compilers don't have a choice, they must pass an address, generally to a local or a field but it could also be an existing address. Quite literally the only way that a copy could be incurred here is if the compiler went out of its way to make one happen. When it comes to initializing a local, the compiler would have to declare two local slots, initialize into one and then copy into the other. I've yet to see a single CLR-targeting compiler, let alone C# compiler, that does something so silly.

But all of this is irrelevant. If you're so concerned that the C# spec leaves any wiggle room for the potential of unnecessary copies, then request that the C# spec be amended to make it abundantly clear. There's zero reason to add redundant syntax to enforce the idea of what the compiler is already going to do, either to the specification or to developers.

[svick]

@ygc369

the syntax itself would still puzzle inexperienced programmers and make them worry about unnecessary copy

If you do introduce this new syntax, then inexperienced programmers will still be puzzled, because they will have two different ways to do the same thing and it will make them worry about which one they should use. I don't think that's a better situation to be in.

[HaloFour]

@YairHalberstadt @ygc369

Dangit, I have to walk that back. The compiler can emit newobj as opposed to call and that will push the struct directly onto the evaluation stack. Assigning that to a variable would incur a copy. I still doubt that any CLR-targeting compiler does this, let alone any C# compiler.

Either way, my second point stands. If you're concerned, raise the issue to have the spec amended. There's zero reason for redundant syntax here.

[yaakov-h]

Doesn't Mono use Roslyn now anyway?