Agree with all. But if 80% of your code can be performant with "ideomatic' code, 15% needing a bit more attention (such as not making use of certain abstractions, like link-to-objects, etc.), with the other 5% requiring diligent attention (Span, etc.) - then your making gradual perf gains as you wish, all within the same language, runtime, and memory pool. This is much better than a re-write and dealing with FFI, or just as likely, full-on serialization between your old code and Rust code.

With that said, there isn't much of an excuse for non-0-cost enumerators, etc. -- given that refactoring tools switch between foreach, linq, indexing or ptr/spanning, you'd think the compiler-chain or jitter could do the same. Roslyn is a better back-end for meta-programming, but it's too bad MS denies us the benefits of surfacing meta-programming to the language or at least tool level, or we'd have tools that could easily convert linq to highly optimized code.

You could also have compiler-enforced "levels" of C# code that had restricted features/semantics, such as "alloc-free", etc. - right now the choice is just "default" or "unsafe".

I think having a mode where LOH allocations are treated as a runtime exception (i.e. with a helpful exception message pointing to the offending object type) could help to guide developers down this path really well. Something like:

"LOH allocation detected for object 'MyNamespace.MyObject'. Attempted allocation bytes: 90K (maximum 85,000 bytes)."

Then one level up from that restriction would be the totally alloc-free approach you mention which could potentially mean the GC could be put into a special idle/framework-only mode. For alloc-free, I believe you could enforce this at compile time, as opposed to run-time for the LOH condition.

Alloc-free would be nice if the CLR/CLI supported it, but I understand there’s too many major architectural changes required, e.g. to allow class object instances to live in the stack and limit their lifetime to prevent an invalid object reference. Even today you can’t `stackalloc` an array unless you’re using `unsafe`.

I’m going to disagree with you that idiomatic C# is somehow unnecessarily “slow”.

The performance overhead of a virtual vs non-virtual call on the CLR is negligible - same as with C++. For proof, look at Direct3D which is performance-critical, yet Direct3D’s API is based on COM which is all about vtable-calls.

Linq itself is also very decent. I won’t argue that Linq is perfect (e.g. suboptimal list allocations when the total output length can be known in-advance), but its hardly “slow” - certainly not enough to impact any production workloads - you’d only observe a difference between hand-written loops and a Linq expression in a contrived synthetic benchmark.

> Direct3D’s API is based on COM which is all about vtable-calls.

It isn’t. It looks like COM, but it isn’t.

Did things change with DX12?

Just asking because this article is quite clear about how DirectX is all about COM: https://docs.microsoft.com/en-us/windows/win32/prog-dx-with-...

> The Microsoft Component Object Model (COM) is an object-oriented programming model used by several technologies, including the bulk of the DirectX API surface. For that reason, you (as a DirectX developer) inevitably use COM when you program DirectX.

DirectX yes, Direct3D no.

I am not sure about D3D9, but 10 and 11 and 12 are not COM.