Roslyn VS .NET Runtime

Local functions do not support overloading

Honestly, I don't have a clue why these would be different. I found the relevant Roslyn code here. You can see on line 719 that this is definitely intentional:

compiler: https://github.com/dotnet/roslyn

Why not use Roslyn Scripting…you can pretty much do any kind of dynamic evaluation with this and it does not require any reflection. https://github.com/dotnet/roslyn/blob/main/docs/wiki/Scripting-API-Samples.md you can add the support via a Nuget.

It was discussed at one point: https://github.com/dotnet/roslyn/issues/5058

It must be a fairly large echo chamber since it has room for Clang, GCC, V8, OpenJDK, Roslyn, etc. (The Zend parser for PHP seems to use some flavor of YACC, but given PHP, I don't know if that strengthens or weakens my point.)

I'm planning to rewrite all of our company's old T4-based codegen tools into Source Generators. I've been looking at how other Source Generators are implemented and what surprised me is that everyone seems to assemble the output code manually as text with string builders or at best some simple templating engine (eg. Scriban). I expected that I would see a lot of projects assembling their output code from Roslyn tokens and then using Roslyn's formatter to produce the actual code that can be emitted into the output file(s), like this article demonstrates. No-one seem to be doing that though. Why?

Clearly nobody ever manages to use this Go thing with over 700: https://github.com/golang/go/issues. Or .net, over 5000 issues for the compiler alone: https://github.com/dotnet/roslyn. I'd guess stuff like Java, glibc would be similar if they used github

To have decimal128, a proposal has to be fledged out. You can read Tanner's comment here for more info: https://github.com/dotnet/runtime/issues/33126

Most projects I have seen just use the Microsoft standards, which in my opinion is rather excellent.

Check the docs out: https://github.com/dotnet/runtime/blob/main/src/coreclr/nati...

Seems to be the case that you just need to install the Microsoft.DotNet.ILCompiler package, and then `dotnet publish...` with the desired target.

Thanks for the feedback! If you have some details and want to post them on https://github.com/dotnet/runtime, we can include them in planning. As you might have guessed, this is a pretty huge long-term project and many things basically need to be rebuilt from scratch in order to be supported.

Debugging is one area where the form factor will likely demand different behavior vs. JIT, so it will be an evolving scenario. It would be great to know what you would expect vs. what you saw, and importantly what you expect to be different from a traditional native debugging experience (like in C++).

This produces a self-unpacking executable that drops all the assemblies somewhere and then runs it. There can be surprising side effects. https://github.com/dotnet/runtime/issues/59715

And check the small print on your platform as to whether it's really single file not requiring any other dependencies alongside it.

dotnet/runtime has a document describing the changes to ECMA-335.

Here is the doc I'm talking about. These are not just "C# features".

Your language inserting casts is not the same as the spec and runtime supporting covariant return types. You can read about some of the challenges with covariant return types in this document.