How does this repo fit in with .NET

[shaggygi]

I recently came across this repo and amazed at some of the work going on here.

The description mentions it is experimental work and could eventually be added to the platform. Please forgive me on the curiosity, but I wanted to know how does this work with the main runtime and BCL. Here are a few questions...

Are there examples/topics that show where some APIs have been moved into the platform that started from here?
Is there a place to read more about progress of moving other work to the platform? And if so, does it include possible timelines that are planned to move (understanding things can change)?
What is the probability of moving the BufferWriter work to the platform?
I'm assuming this is a Microsoft effort being under the dotnet org. Is this mainly worked on as a side project or is it a real location used to start off concept work by the .NET teams?
Why is this repo used instead of runtimelab?

Thanks for any response and keep up the good work.

[sakno]

@shaggygi , strictly speaking, it doesn't. BCL has many proposal that are not implemented (yet or probably never will be). However, they were requested by the community. Due to specific process of new API approvals and the specific vision of .NET development from MS side (which is not clear, at least for me), providing requested features may take a long time. I'm observing this situation many years as a contributor to .NET codebase as well as to this repo.

As a result, I chose the following strategy:

• Create open-source project
• Contribute it to .NET Foundation to be close to .NET itself as much as possible
• Develop the features missed in original .NET with a quality suitable for production use. This is main difference with runtimelab repo. All features shipped as tested and signed packages on NuGet respecting SemVer versioning policy.
• Propose these already implemented features to .NET team

At README file, you can find a table (on the top) that has a links to proposals that were implemented in the current repo first or later as a response to community request. From my side, I'm trying to promote already implemented features to .NET. Of course, in reality it's very hard. That's why I prefer to distribute them as a separated packages to get the value to the developers as fast as possible.

Some features will never be merged into .NET main branch. For instance, DotNext.Metaprogramming library provides support of async/await operators in LINQ Expression Trees. .NET Team decided to stop active development of Expression Trees. Therefore, these extension are available only through separated library.

In other words, the philosophy of this repo is the following: provide valuable extra API without alignment with .NET release lifecycle. One more important aspect: this repo doesn't have a goal to make experiments with the runtime itself (GC, JIT/AOT compiler, IL instructions). Otherwise, we have to ship and support customized version of CLR.