Added: LDM Notes for March 29th, 2021

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2021/LDM-2021-03-29.md

Agenda

1. Parameterless struct constructors
2. AsyncMethodBuilder

[jnm2]

By that rule, option 1 should be the tack we take. However, we are also concerned that some users will have taken a dependency on that parameterless constructor meaning a 0-initialized struct.

What about users who have been carefully using default(S) when they wanted zeroed memory and new S() when they wanted a ready-to-use instance that would be resilient to refactoring S to a class or adding a default struct constructor when this day came?

[MgSam]

They don't matter. :) A chain is only as strong as its weakest link.

[jnm2]

I don't understand what the weak link is in this scenario.

[MgSam]

we are also concerned that some users will have taken a dependency on that parameterless constructor meaning a 0-initialized struct.

Users doing this...

[jnm2]

Oh. The antecedent for "they" wasn't clear underneath me talking about the opposite kind of user.

[AartBluestoke]

var t = new T();
System.Console.WriteLine(t.Field);

public struct T {
    public int Field;
   ... code that doesn't alter Field ...
}

Personally I would be surprised if that (current behaviour) printed anything other than 0.

var s = new S();
System.Console.WriteLine(s.Field);

var sc = new Sc();
System.Console.WriteLine(sc.Field);

public struct S {
    public int Field = 42;
   ... code that doesn't assign Field ...
}
public class Sc {
    public int Field = 42;
   ... code that doesn't assign Field ...
}

Similarly, personally, i would be surprised if that (proposed behaviour) printed anything other than 42, as that is what a Class would do.

Given that this feature is "opt in" (ie, you don't have to define a non-0 default)
| we are also concerned that some users will have taken a dependency on that parameterless constructor meaning a 0-initialized struct.
should not be a group of people we need to optimise for.

Has there been any review of the potential size of this group of people, or checks if any major libraries would be affected this? (i would guess primarily serialization libraries would expect 0 init; asp.net, newtonsoft, Jil, Protobuf .... the list at https://aloiskraus.wordpress.com/2019/09/29/net-serialization-benchmark-2019-roundup/)

[orthoxerox]

I prefer option 2 plus a warning if a type with a no-arg constructor is initialized via default.

[HaloFour]

The complication here comes from the fact that new S() was and will continue to be legal, even when there is no parameterless constructor.

And it has always meant to invoke a parameterless constructor, if one exists, otherwise zero out the struct. Granted the odds of running into such a beast was probably quite rare given the lack of support for it in the major MS .NET compilers, and I imagine that it will continue to be rare even after the introduction of this feature. I'd rather the compiler emit the default parameterless constructor for the initializer here. I feel that doing anything else will be more surprising and lead to more bugs. Otherwise, if the team goes with not emitting a default parameterless constructor, I would leave instance field and property initializers illegal.

[MgSam]

While I think resolving this gap in the language would be nice, as the notes imply, none of the 3 possibilities comes across as "obviously" better. Some users are likely to be surprised no matter what option is chosen. Given that, I think doing nothing might be the best option.

Also, I don't really understand what the motivation for doing this proposal now are. The motivation in the proposal document is entirely technical and has no business use-cases listed (performance benefits, scenarios currently blocked, etc). This seems like a minor annoyance that we've lived with for 20 years already and its not worth making potentially confusing changes to try and fix it.

[BreyerW]

personally I wish there was way to construct struct with custom default values like classes (and if i understand correctly ldm notes here it could be enabled as one of the options). This would help making sure struct is always in correct state after constructing. Of course you can use factory pattern but when new to project developers comes along, for him constructing that struct with factory is not necessarily obvious immediately. With option 1 we could reduce chances of bugs due to invalid state. Also today all structs are barebone (that is dont have initializers) anyway meaning they are zero-inited satisfying the dependency on parameterless constructor giving zero-inited struct. Only new code may potentially break that dependency but you have to do it consciously anyway and any mistakes from that are on you imo. Of course another way would be to make better IDE experience with factories and if memory serves right team was even interested in this avenue but so far nothing concrete materialized not even official proposal

setting that aside i personally believe it should be either 1 option or 2 but definitely NOT 3. The example provided in notes is perfect explanation why. (it is too suprising with option 2 you get at least a warn)

[qrli]

1. There is an implicit parameterless constructor that runs the field initializer. The code sample would print 42.

However, we are also concerned that some users will have taken a dependency on that parameterless constructor meaning a 0-initialized struct.

So, the ideal behavior is 1, while the others are only for the reason of backward compatibility in case the struct has instance field initializers.

Why not do 1 and issue an warning in case it has any instance field initializer?

[Joe4evr]

Why not do 1 and issue an warning in case it has any instance field initializer?

How do you propose the compiler detect that a given struct has instance field initializers in it? Especially in the face of ref assemblies that remove method bodies et al.

[qrli]

Good question. I missed that part.
More thinking: as this is a backward compatibility concern, is it really necessary to warn at all? Field initializers are not allowed on structs today, so no break on existing code. Only for new code, there could be a difference.

[jnm2]

@Joe4evr I'd expect the reference assembly definition to adapt to future changes in C#, based on https://docs.microsoft.com/en-us/dotnet/standard/assembly/reference-assemblies#reference-assemblies-structure:

Private function-members (methods, properties, and events) are removed in cases where their removal doesn't observably impact compilation.

[DavidArno]

I figure this would be a good place to resurface an idea that some of us raised a while ago: non-zero default structs. I feel that the reason that all three of the options for parameterless struct constructors are less than ideal are because none of them address the underlying issue that sometimes we want the default value of a struct to be something other than zero.

I'm not sure if "blitting" is the right term here (I picked the term up up from the "Blitter" coprocessor in the Commodore Amiga's Agnus chip) but as far as I know, copying a value from one memory location to another is not significantly slower than zero-filling that location. In fact, I suspect it gets very chip-specific in terms of the speed of moving values from registers versus caches as I'd be surprised if there was any measurable difference in real-world scenarios. It therefore seems sensible to me that the team investigate having the compiler precompute the default values of structs and have default(S) blitt those values to the stack/heap so we get non-zero struct support.

It may not work, but I'm not aware that its ever been investigated, so we don't know that. And if it is viable, then the issue of how to handle new S() becomes a lot simpler.

[YairHalberstadt]

The default value of a struct could be limited to being a static readonly field, which must be initialized by a new Struct(optional params){optional initializers} expression.

[Joe4evr]

I'm not sure if "blittering" is the right term here

I'd go with "blitting".

[DavidArno]

I'm not sure if "blittering" is the right term here

I'd go with "blitting".

Doh, that was a spelling mistake on my part and should have said "blitting". Corrected & thanks. 😀

[alrz]

@DavidArno Hi!