Make C# more modular

[HappyNomad]

I'm new to Roslyn and have so far only had a broad overview of it. I have not at all delved into its internals. So naturally I have a half-baked, completely naive idea that I'd like to share 😜 . Before you close it, please provide some feedback about how it relates to existing initiatives and capabilities.

With so much talk about making the .NET Core framework modular, I wonder about the C# language itself being more modular as well. If this feature existed, perhaps existing language features like 'async'/'await', 'yield return', and the LINQ keywords could be repackaged as extensions in their respective assemblies, outside the core Roslyn library. The point though of course would be to allow for new and experimental language features to be easily plugged into existing classes or projects. It may be easier to experiment building, sharing, and trying out features this way.

The keywords would be defined in their respective assemblies: 'async'/'await' within the TPL, 'yield return' within the BCL, the LINQ keywords within System.Core. These external assemblies would provide metadata to the compiler/IDE such that the defined keywords "light up" in the text editor and get properly interpreted during compilation. The available language keywords would depend on the referenced assemblies and imported namespaces. This means that "standard" keywords like those mentioned above would remain standard since they live inside commonly referenced assemblies.

The major omission from this post is of course the shape that these keyword providing assemblies would take and how they would interact with the compiler. It would be an interesting to start by trying to externalize 'async'/'await', 'yield return', and the LINQ keywords and then see what API would be necessary to make that possible.

[tannergooding]

Tagging @dotnet/roslyn-compiler.

[AdamSpeight2008]

Reminds me of #5622

[dsaf]

It would be great not to wait 2 years and get everything in one go. I thought that was one of the reasons for re-writing the compiler. Last big feature async happened 4 years ago now.

[alrz]

I don't know what is bad about frequent language releases, Rust for example releases a minor version every month or so, and there is a nice three-channel release model for showcasing experimental features and progressive stabilization.

[HappyNomad]

I finally got around to updating my original comment in response to some of the replies.

• I removed mention of "language profiles" since it was outside the main point and in fact unnecessary anyway.
• Also, I want to clarify that this idea applies only to keywords that involve compile-time code generation, as exemplified by the three existing language features mentioned. I believe that the C# language should continue evolving and standardizing in the manner it currently is. However, I think that the aforementioned class of keywords should belong to their respective libraries rather than the core language spec/library.

[gafter]

The major omission from this post is of course the shape that these keyword providing assemblies would take and how they would interact with the compiler. It would be an interesting to start by trying to externalize 'async'/'await', 'yield return', and the LINQ keywords and then see what API would be necessary to make that possible.

@HappyNomad We're very interested in how your experiments progress. Please keep me informed. If you need any help along the way with whatever approach you decide to take, please feel free to ping me.

[HappyNomad]

@gafter Sorry, my hands are rather full and so the first paragraph of my original comment still holds. I really do hope that someone else steps up to the plate, though.

[gafter]

We are now taking language feature discussion in other repositories:

• https://github.com/dotnet/csharplang for C# specific issues
• https://github.com/dotnet/vblang for VB-specific features
• https://github.com/dotnet/csharplang for features that affect both languages

Features that are under active design or development, or which are "championed" by someone on the language design team, have already been moved either as issues or as checked-in design documents. For example, the proposal in this repo "Proposal: Partial interface implementation a.k.a. Traits" (issue 16139 and a few other issues that request the same thing) are now tracked by the language team at issue 52 in https://github.com/dotnet/csharplang/issues, and there is a draft spec at https://github.com/dotnet/csharplang/blob/master/proposals/default-interface-methods.md and further discussion at issue 288 in https://github.com/dotnet/csharplang/issues. Prototyping of the compiler portion of language features is still tracked here; see, for example, https://github.com/dotnet/roslyn/tree/features/DefaultInterfaceImplementation and issue 17952.

In order to facilitate that transition, we have started closing language design discussions from the roslyn repo with a note briefly explaining why. When we are aware of an existing discussion for the feature already in the new repo, we are adding a link to that. But we're not adding new issues to the new repos for existing discussions in this repo that the language design team does not currently envision taking on. Our intent is to eventually close the language design issues in the Roslyn repo and encourage discussion in one of the new repos instead.

Our intent is not to shut down discussion on language design - you can still continue discussion on the closed issues if you want - but rather we would like to encourage people to move discussion to where we are more likely to be paying attention (the new repo), or to abandon discussions that are no longer of interest to you.

If you happen to notice that one of the closed issues has a relevant issue in the new repo, and we have not added a link to the new issue, we would appreciate you providing a link from the old to the new discussion. That way people who are still interested in the discussion can start paying attention to the new issue.

Also, we'd welcome any ideas you might have on how we could better manage the transition. Comments and discussion about closing and/or moving issues should be directed to #18002. Comments and discussion about this issue can take place here or on an issue in the relevant repo.

---

I have not moved this feature request to the csharplang repo because I don't believe it would ever rise in priority over other requests to be something we would ever do in any particular release. Moreover, it undermines the idea that C# is a language that obeys its specification, since presumably these extensions would permit programs to do things the underlying language specification does not allow. However, you are welcome to move discussion to the new repo if this still interests you.