Added: LDM Notes for April 28th, 2021

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2021/LDM-2021-04-28.md

Agenda

1. Open questions in record and parameterless structs
2. Improved interpolated strings

[alrz]

using a tuple expression: $"{("structureName", myExpression),alignment:format}". It is possible to construct interpolated string builders that only accept tuples of string and T in their interpolation holes

Will this work if we had static void AppendFormatted<T>(this ref InterpolatedStringBuilder, (string, T))?

Logging frameworks could definitely take advantage of that so there wouldn't be a need for runtime parsing of message templates.

[333fred]

Will this work if we had static void AppendFormatted(this ref InterpolatedStringBuilder, (string, T))?

No, the logging framework would define its own builder type, not reuse an existing one. Even if we looked for extension methods on builder types (which we don't), it would never be preferred over the instance method AppendFormatted<T>(T t)

[HaloFour]

This was discussed a little on Discord but I'll post my findings here as well.

TL;DR: For a struct with field initializers and without a parameterless constructor, emit a private parameterless constructor. Will handle the warning/error on new S() without needing a warning wave with a large blast radius and also closes the generic hole.

Per the design notes the plan is to not synthesize a parameterless constructor for a struct that has field initializers. This will mean that the current behavior of new S() will continue to mean default(S) and those field initializers will not be invoked. The plan is also to introduce an opt-in warning wave to warn on the use of new S() on any struct that has a constructor with parameters but without a parameterless constructors, as the compiler would not be able to distinguish between a struct that has field initializers from one that doesn't based only on assembly metadata.

This approach has a very large blast radius, since it applies to a lot of structs, and the developer must opt-in otherwise they would not have any indication that field initializers might not be executing. This approach would certainly make sense if the eventual goal is to make new S() illegal (and a compiler error) if the struct does not have a parameterless constructor, but I doubt that the team has the appetite for that.

Since these structs with field initializers would be a brand new beast in C# 10.0 I suggested the use of some metadata on the struct which would denote that these structs have field initializers. This would allow the compiler to more narrowly focus the compiler diagnostic to only apply to new structs, which would also mean that it would not have to be a warning wave. It could even be a compiler error, further forcing the developer to explicitly decide between default(S) vs. a constructor with parameters. This, however, still leaves the generic hole.

So I suggested that the metadata applied to these structs actually be a synthesized private parameterless constructor. In theory the C# compiler already supports consuming structs with parameterless constructors so it should also already prevent using new S() on a struct with such a private parameterless constructor.

Unfortunately, in testing I found that this is not the case. The C# compiler will happily allow you to use new S() on a struct that has a private parameterless constructor and will emit an initobj instead of erroring on the accessibility of the constructor. The compiler also lets you use the struct as a generic type argument to a generic parameter constrained to struct, although that will fail at runtime.

I would imagine that both of these issues will be dealt with as a part of implementing parameterless ctors in structs. As such, what I propose is that if a struct is declared with field initializers and does not declare a parameterless constructor that the compiler emits a private parameterless constructor. This constructor would serve as the metadata to indicate that it is not safe to create the struct with new S(), which the compiler should enforce by the accessibility of that constructor. This would be narrowly applied as it would only affect new structs defined with field initializers. It would also affect other such structs that might be out in the wild, but I imagine that such structs are incredibly rare, if they exist at all, and that the behavior of using new S() with them is already incorrect and should be fixed.

Another advantage of emitting a private parameterless constructor is that it helps to close the generic hole. The runtime is already doing its part and such a struct cannot be used with a generic method that has either the struct or new() generic constraint. The compiler would need to be fixed to correctly identify such structs and to produce a compiler error when such a struct is used as a generic type argument.

Thoughts?

[333fred]

I think something was a bit unclear in our conversations and in the notes, which I've updated to make clearer. Specifically:

The plan is also to introduce an opt-in warning wave to warn on the use of new S() across the board for structs without parameterless constructors

This isn't quite correct: It's for structs that do not have a parameterless constructor and have a constructor with parameters. Still a pretty big radius, but not quite all structs.

[HaloFour]

As noted, this approach would be a breaking change. Specifically, changing the behavior of the compiler where it supports consuming structs with parameterless constructors to recognize and respect the accessibility level of said constructor would be a breaking change. However, I would posit that this is a bug today, and @333fred already stated that he was surprised that the compiler behaved in this manner. I also posit that the likelihood of this actually breaking code is negligible to the point of being nonexistent. If projects did rely on these kinds of structs they would've already been broken by the bugs with Activator.CreateInstance that were already fixed by the runtime in both .NET Core and .NET Framework.

[HaloFour]

@333fred

This isn't quite correct: It's for structs that do not have a parameterless constructor and have a constructor with parameters. Still a pretty big radius, but not quite all structs.

Thanks for the clarification. That is a smaller blast radius, but it still applies to a lot of structs that are used in the wild.

I've updated my diatribe to reflect the clarification.

[HaloFour]

In further conversion I missed one aspect of the "generic hole". Specifically I missed that if the struct constraint continues to imply new() that any struct declared with a non-public parameterless constructor could not be used as a generic type argument to that generic type parameter. To me this is a bit of a problem because if C# allows you to declare a struct with a non-public parameterless constructor, regardless of my suggestion above, that it would never be safe to use that struct as a generic type argument. The compiler might successfully compile due to the existing "bug", but the runtime will definitely throw an exception if at any point that generic method attempts to new() that struct.

I don't have an answer for how to address this. Attempting to tease apart struct and new() would be a big breaking change and affect a lot of code. But allowing those structs to be used as generic type arguments in this case seems like it would create a really bad type safety problem which will result in exceptions at runtime. IMO a warning wave is not sufficient here and I really think that the language design team should revisit "holding their nose" and ignoring this.