Added: LDM notes for March 23, 2020

[agocke]

https://github.com/dotnet/csharplang/blob/master/meetings/2020/LDM-2020-03-23.md

[HaloFour]

Thank you @CyrusNajmabadi for being willing to take up my thrown-together struct builder design and presenting it. I'm sure it's not perfect but I think it's something that could be iterated upon.

I understand that there are a lot of competing ideas around how init and withers could be designed with a lot of different competing and incompatible priorities. I don't view "records" as a new feature, at least in their currently proposed form. To me the feature represents an attempt to reduce boilerplate from POCOs, one of most commonly written and used pieces of code on the planet. To that end I heavily prioritize compatibility with the ecosystem, not just with other .NET languages but also with the wide array of frameworks that are designed to work with and serialize/deserialize POCOs. Building the feature in such a way that requires revving the runtime will put all of those frameworks into the position of having to choose whether to target newer runtimes and cut compatibility for their audience. I'd think that a poll of those commonly used frameworks would show that few require .NET Core and even fewer require .NET Core 3.x. If POCO v2 can't be used from the multitude of frameworks developers use to store and transport them it will create a tension between developers who want to use a feature that eliminates their boilerplate and frameworks that want to maintain compatibility with a larger audience of older and deprecated runtimes.

[HaloFour]

Also, I know this is not a popular opinion, but I believe that the best use case for additive-only source generators is records. At least the nominal variety. I think projects like Lombok demonstrate this quite well and offer developers lots of options to define the shape of the type. Thousands of policy combinations to choose from, many more than any suite of language features could offer, and compatible with all versions of Java since annotation processors were introduced.

IMO, the language would be better served trying to target those novel cases that can't be achieved with current language features, like case classes, DUs/ADTs, etc. Or rather targeting the features that would enable those types to exist and be used in pattern matching scenarios. Declaring a "war on boilerplate" only creates a war on what that generated boilerplate is supposed to look like.

[Joe4evr]

Building the feature in such a way that requires revving the runtime will put all of those frameworks into the position of having to choose whether to target newer runtimes and cut compatibility for their audience.

See also: the community split of Python 2 vs 3.

[qrli]

Some premature thinking:
With some special design of the builder pattern, it should be possible for a new version of the runtime to optimize out the extra memory usage and copying. Just like Vector, which still works on old runtimes while optimized with SIMD on newer runtimes.

[agocke]

@HaloFour Point taken, but I do want to note that the alternative init-only designs only require updated compilers, not necessarily an updated runtime. Usage of a newer version of C# on older frameworks would be unsupported, but that would be true regardless of the code generation pattern.

The only feature that I know of that would require runtime changes is the Withers when a record is inheriting from another record. That requires covariant returns.

[HaloFour]

When we tried to extend the behavior for IDisposable we ran into a problem because foreach conditionally disposes things which match the IDisposable pattern.

I've mentioned this before and it very well could have been brought up during the meetings but not addressed in the notes so I apologize for sounding like a broken record, but is there a reason that IDisposable couldn't be a pattern except for enumerators used with foreach? I admit that this may cause a little confusion in that disposing would be sometimes be pattern based and sometimes not, although that is already the case with ref structs. And there is precedent in the language for a feature to be partially pattern based and partially require interface implementation: await.

[alrz]

@HaloFour

couldn't be a pattern except for enumerators used with foreach?

I suspect the team counts on defer to be the remedy.

Even with a pattern-based disposable, there are some APIs that could not use that, for example, pool management.

var builder = ArrayBuilder<T>.GetInstance();
defer builder.Free();

var array = ArrayPool<T>.Shared.Rent(size);
defer ArrayPool<T>.Shared.Return(array);

[alrz]

BTW to me, it does make sense to say

foreach calls Dispose only if the type implements IDiposable, and
using either uses that or calls any accessible Dispose method.

but I'm not sure if that would worth it if it doesn't cover those cases.

[HaloFour]

@alrz

I suspect the team counts on defer to be the remedy.

I kind of don't doubt it, although defer still has a bunch of design to go through. I think everyone knows my opinion on defer, and IMO it's necessity comes mostly from resource APIs that have not followed the resource pattern. But having defer only encourages more APIs to not follow the resource pattern, since there would no longer be a pattern to follow, so that becomes more a self-fulfilling prophecy.