Field initializers in structs can often lead to friction points for authors

[CyrusNajmabadi]

This discussion is extracted out from the (sometimes intense) discussion that occurred on the following issue: #5552

The crux of the problem is that there is a bit of an ergonomic cliff you fall off of when you transition from writing structs like so:

struct Vector3d
{
    double X, Y, Z;
}

var v = new Vector3d();

versus something like:

struct MagnitudeVector3d
{
    double X, Y, Z;
    double Magnitude = 1;
}

var m = new MagnitudeVector3d();

Due to the change the LDM decided on https://github.com/dotnet/csharplang/blob/main/meetings/2022/LDM-2022-01-03.md#parameterless-struct-constructors-revisited, the latter is no longer legal, and the user must provide a real constructor to initialize the struct. We want the user to provide a constructor explicitly as we do not want to synthesize an implicit no-arg constructor here that would then disappear if they ever added a has-arg constructor.

That said, for the user, adding this constructor is not pleasant. They end up having to write things like:

struct MagnitudeVector3d
{
    double X, Y, Z;
    double Magnitude = 1;

    public MagnitudeVector3d()
    {
        X = 0;
        Y = 0;
        Z = 0;
    }
}

// or something like:

struct MagnitudeVector3d
{
    double X = 0, Y = 0, Z = 0;
    double Magnitude = 1;

    public MagnitudeVector3d()
    {
    }
}

Both of these approaches are necessary so that the struct is definitely-assigned (DA) on constructor exit.

Note that this friction is a particular problem for the no-arg constructor. For any with-arg constructor, we always supported the user writing things like the following:

struct Vector3d
{
    double X, Y, Z;

    public Vector3d(double X) : this() { /*... */ }
}

In other words, you could always chain the with-arg constructor to teh no-arg constructor. A constructor always leaves the struct def assigned, so this always worked as the chained constructor init'ed everything to zero, and then the actual constructor logic could run after that.

However, there's no equivalent for the no-arg constructor if the user provides it. the user cannot write:

struct MagnitudeVector3d
{
    double X = 0, Y = 0, Z = 0;
    double Magnitude = 1;

    public MagnitudeVector3d() : this()
    {
    }
}

As this would be a circular reference. They also can't do:

struct MagnitudeVector3d
{
    double X = 0, Y = 0, Z = 0;
    double Magnitude = 1;

    public MagnitudeVector3d()
    {
        this = default;
    }
}

As this would blow away the initialized for Magnitude, defeating the purpose of having initializers in the first place.

--

There are things we could do here though to make things more palatable for the user (with varying levels of pros/cons).

Options:

1. Consider changing how DA works in these cases. For example, if any field was "not-assigned-along-any-path-on-exit" (insert handwaving here on how to precisely state that), then it could be assigned to default on exit leaving the struct in a DA state.
   1. Pros, it would allow the user to just write public MagnitudeVector3d() { } and get reasonable behavior.
   2. Cons, it touches DA and coudl be hugely complex to specify this precisely (and implement).
2. We could always have all constructors initobj the struct at the start.
   1. Pros, it would allow the user to just write public MagnitudeVector3d() { } and get reasonable behavior.
   2. Cons, it might really add a perf cost because of the redundant initialization (though potentially we could detect and emit good code with high complexity to only init what is necessary).
3. We could introduce a whole new syntax to let the user opt into this. For example: public MagnitudeVector3d() : default {}
   1. Pros, it lets the user just write that simple form, and not have to care about individual assignment.
   2. Cons, it's a full new feature with new syntax. We'd also have to figure out how this would work with primary constructors with record-structs. Though perhaps public record struct Foo(double X, double Y) : default { } is totally sufficient for taht.
4. we could have a generator always synthesize this explicit no-arg constructor (if not already there). it would assign any fields without initializers. Other constructors could then chain to this.
   1. Pros, nothing for the user to do (except maybe add an attribute).
   2. Cons, Need to create and support this analyzer. Potential user confusion about what was going on here.

[TahirAhmadov]

I don't have a dog in this fight as much as some others because my usage of structs is usually limited to simple scenarios which are handled fine from earliest versions. Having said that, may I suggest that somebody who is intimately familiar with all possible permutations of struct initialization and construction, puts together a short document (in any format) that demonstrates all these use cases? Such as local vs array vs class field (I suspect last 2 are the same) etc., and struct field initializer vs constructors, etc. If something like this already exists, a link would be good. At this point I'm trying to understand the topic but it has become so convoluted I can't quite wrap my head around. I have a feeling some others may be in the same boat.

[cston]

@TahirAhmadov, see parameterless-struct-constructors.md for a description of the changes in C#10 to support parameterless constructors and field initializers in structs.

I'll update that document based on the recent decision to not synthesize a parameterless constructor.

Let me know if there are aspects of that document that are unclear, thanks.

[TahirAhmadov]

@cston Thank you!

[YairHalberstadt]

I think I would prefer that the compiler just always synthesized the no args constructor, and only warned on records which have a field initialiser and no no args constructor. Forcing the user to write it is just busy work.

[oising]

To suggest a slight modification to this, if someone chooses to initialize all fields inline, then allow omitting the no-args empty ctor (and synthesize it instead.)

[HaloFour]

That's what the compiler does now and what the language team wants to change.

[RikkiGibson]

I think I would prefer that the compiler just always synthesized the no args constructor

I may have a struct where I have multiple constructors with parameters, and no parameterless constructors, and I use field initializers, and it doesn't make sense for my struct to introduce a parameterless constructor. If we synthesized one, we would certainly enforce definite assignment or at least nullability requirements on the synthesized parameterless constructor. It catches the user in a situation where we're asking them to do something that doesn't make sense.

using System.Collections.Generic;

public struct Widget
{
    public readonly List<string> items = new List<string>();
    public readonly string name;
    public readonly string key;
    
    public Widget(string name)
        : this(name, GenerateKey())
    {
    }

    public Widget(string name, string key)
    {
        this.name = name;
        this.key = key;
    }
    
    private static string GenerateKey()
    {
        return "1";
    }
}

[oising]

That's what the compiler does now and what the language team wants to change.

Not quite -- the 6.0.100 compiler will let you initialize some of the fields and also omit the ctor. This is a bug. I'm suggesting that to comply with definite assignment rules, allow omitting the empty ctor only if all of the fields have been initialized. The team is suggesting that even in this case, you'd still need to write an empty ctor.

[iam3yal]

Cons, Need to create and support this analyzer. Potential user confusion about what was going on here.

I think that the confusion already exists here when it comes to inconsistencies between structs vs classes in general but more than that having to write anything for that although might be necessary is confusing too.

[foxesknow]

I agree, and feel like we're making structs more and more confusing.

[TahirAhmadov]

What if we just said, struct follows the same rules as class WRT ctors. Basically, the only time a public no-arg ctor is synthesized is when no other ctor is present. If field initializers are present, the synthesized ctor calls them. Other fields are zeroed out.
For any explicit ctor, all fields without initializers and those not set in the ctor, are zero set; fields with initializers are set to initializer value.
Note: the above zero-setting of un-initialized fields is also consistent with how classes behave.
Then, if no-arg ctor isn't available (explicit or synthesized), existing code like new Struct() (which used to mean default(Struct) pre-C#10) becomes a warning, saying it will be interpreted as default(Struct), with an IDE auto-fix to default(Struct).
If no-arg ctor is available, new Struct() is fine; it calls that ctor - explicit or synthesized.
Pro: consistency and ease of understanding; no effort from users, except for pushing them to avoid new Struct() as equivalent to default(Struct) in the rare cases of no public no-arg ctor - which is a good thing by itself, we're getting rid of a wart in the language.
Con: level of effort (new warning, IDE work), may be a break with C#10 (but that's accepted already)

struct MagnitudeVector3d
{
    public double X, Y, Z;
    public double Magnitude = 1;
}
var m = new MagnitudeVector3d(); // OK
Console.Write(m.X/Y/Z); // writes 0
Console.Write(m.Magnitude); // writes 1

struct MagnitudeVector3d
{
    public MagnitudeVector3d()
    {
        this.X = 2;
    }
    public double X, Y, Z;
    public double Magnitude = 1;
}
var m = new MagnitudeVector3d(); // OK
Console.Write(m.X); // writes 2
Console.Write(m.Y/Z); // writes 0
Console.Write(m.Magnitude); // writes 1

struct MagnitudeVector3d
{
    private MagnitudeVector3d()
    {
        this.X = 2;
    }
    public double X, Y, Z;
    public double Magnitude = 1;
}
var m = new MagnitudeVector3d(); // WARNING: no public ctor; treating this as default(MagnitudeVector3d)
Console.Write(m.X/Y/Z/Magnitude); // writes 0

void Foo<T>() where T : struct 
{
  var t = new T(); // warning: presence of parameterless public ctor is not known, therefore this is treated as default(T); use that instead
}
Foo<MagnitudeVector3d>(); // OK

void Bar<T>() where T : new()
{
  var t = new T(); // OK
}
Bar<MagnitudeVector3d>(); // WARNING: no public ctor; generic new MagnitudeVector3d() will be treated as default(MagnitudeVector3d)

[HaloFour]

Here are the meeting notes where this was discussed: https://github.com/dotnet/csharplang/blob/main/meetings/2021/LDM-2021-12-15.md#warnings-for-parameterless-struct-constructor

[TahirAhmadov]

That item only says it's a broad hammer and while I agree generally, it's a case of "you get what you pay for".
Yes we pay introducing a warning that can affect a lot of code. (We can take steps to mitigate the actual impact on users.)
But, we also get a lot out of it. Imagine a world where you don't have to remember a second set of rules with structs and ctors. Consistency is king, queen and all the princes and princesses.
Another point: somebody else in another thread was unhappy that high-performance techniques in C# require extra knowledge and special approaches, which keep a portion of the user base away from using them. Given that (in some cases) structs can deliver good performance gains, making them easier to use would be a big boost to performance-minded coding.

[TahirAhmadov]

"We think this option is like attempting to use a sledgehammer to drive in a finishing nail." - yes the finishing nail is driven in, but also a few huge rail track nails are, too. It's not just the finishing - the trains have to run, as well.

[RikkiGibson]

I think a major concern with making new() a warning when no parameterless constructor is present is object initializers.

struct S
{
    public int x, y;
}

// it's unfortunate to "miss out" on object initializers here
var s = new S
{
    x = 1,
    y = 2
};

[TahirAhmadov]

@RikkiGibson to clarify, that would be perfectly legal. Your S has no explicit ctors, and therefore gets a synthesized (implicit) public no-arg ctor - just like classes do.

[RikkiGibson]

#5737 will be available in preview in 17.3 and alleviates some of the friction points here.