Added: LDM Notes for July 12th, 2021

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2021/LDM-2021-07-12.md

Agenda

1. C# 10 Feature Status
2. Speakable names for top-level statements

[HaloFour]

2. Speakable names for top-level statements

Would those top-level statements be permitted within a namespace? If so, does the synthesized partial Program class get generated within that namespace?

The one thing that would give me pause here would be if/how that could evolve into more general top-level functions and how those functions might then be organized under namespaces.

[333fred]

Currently, we believe that you will not be allowed to put them in a namespace.

[HaloFour]

Got it. Any concern that the codegen and speakable names will impact the ability to allow that in the future? Or to eventually expand on the feature to allow top-level functions to be declared in other source files and under a namespace?

[MgSam]

When did parameter-null-checking become !!? The feature status page references this issue which references two LDMs one of which says "maybe" it should be !!. The feature spec says nothing about !!.

[HaloFour]

https://github.com/dotnet/csharplang/blob/main/meetings/2020/LDM-2020-06-24.md#Parameter-Null-Checking

[qrli]

Can anyone confirm my understanding "This feature affects only method implementation but not method signature" is still correct now?

[333fred]

Yes, that is still correct.

[MgSam]

@HaloFour Thanks.

Even with reading the LDM every week, it is really hard to follow the evolution of these features when the proposal docs don't get updated. Surely the LDT must keep these notes collated together somewhere; I can't imagine every member of the team keeps the entire evolution of every feature across many LDM solely in their heads.

[HaloFour]

You can find all of the notes under here: https://github.com/dotnet/csharplang/tree/main/meetings

The README for each year will break down each of the major subjects discussed at each meeting. That's how I found the notes for parameter null checking. Does still involve a little bit of scanning.

The team has been pretty good about linking new notes in the proposals affected by them but that can also easily get lost especially on an issue with a ton of comments like that one where you end up having to click the Load button a ton of times. :/

[dfkeenan]

No mention of the field keyword in the LDM notes or the features doc. I guess it really isn't making it for C# 10. 😞

[CyrusNajmabadi]

There is almost no way it would make it for C#10. It's too large and the team has no spare cycles for this.

[dfkeenan]

That's OK. I know you guys are working hard to make the magic happen. I'm just super keen for this feature.

[Mrxx99]

Why not name the top level program class like the file name instead of 'Program'? That would feel the most natural (at least for me) and then would not be a change if later one multiple top level files would be allowed.

[333fred]

This is an interesting idea that wasn't brought up in the session. It might be worth considering. @MadsTorgersen, what do you think?

[HaloFour]

This is what Kotlin does: Utils.kt -> class UtilsKt

[CyrusNajmabadi]

I hate adding the extension. I am ok with the idea of the filename being the class name hint though :)

[HaloFour]

Agreed, I don't like the inclusion of the extension in the class name. I think it's largely an implementation detail as you almost never have to think that the class exists. The Kotlin compiler automatically makes those top-level functions into static methods in a static class under the specified package. Importing the package automatically imports all of those static methods. IMO it's a nice approach for simulating top-level functions in a JVM language. So as a Kotlin developer you never have to be concerned about the class name. It only really matters when interoping from other JVM languages, and Kotlin does offer a way to change the name of the generated class.

I'm not necessarily suggesting that C# should adopt this approach for top-level functions, but I do think that it is of the simpler approaches and would interop easily with any other .NET language.