1. Pointers to the same (and not just references to objects).
2. Unions (via explicit-layout structs)
3. Function pointers.
4. C-style varargs.
To be fair, not all of these have been exposed in C# historically even though CLR had them all along. Most notably, unmanaged function pointers took over 20 years. And since most people look at CLR through the prism of C#, they aren't necessarily aware of these features.
Still, one way or the other, we're at the point where pretty much any C program can be transpiled to C# in a one-to-one mapping of almost every construct (setjmp/longjmp has to be emulated with exceptions), and a very similar performance profile of the resulting code.
5. Stackalloc (C alloca), fixed buffers in structs and inline arrays
6. ref T and Span<T>, which act just like &mut T and &mut [T] in Rust (with the same syntax). They are used in both advanced and most basic APIs alike to provide zero-cost wrapping and/or slicing of arbitrary memory (managed heap, stack, NativeMemory.Alloc'd)
e.g. You can receive byte* and length from FFI and construct a (ReadOnly)Span<byte> from them. That span then can be passed to almost every method that used to work with arrays only during .NET Framework days.
Indeed.
The CLR from its inception implemented a lot of features for helping native inter-op. I would guess that msft did make the effort simply because of their large legacy c/c++/win32 code base.
It's a shame really that msft stewardship of the .net/clr was so lacking. Of all the modern virtual machine clr us pretty much up there
The goal wasn't so much native interop as being the universal VM for different languages. Specifically, they had an explicit requirement that pure CLR bytecode should be a valid compilation target for C++ (among other things - such as what would eventually become F#, hence why CLR also has explicit tailcalls, for example). But, of course, when you have all the necessary abstractions, that also allows for easy interop with the world outside the VM.
It's too bad that this vision was never fully realized - in part, because .NET was not open enough originally, but also because of internal divisions in Microsoft itself. If it did, we could have had the equivalent of both LLVM and WebAssembly much, much earlier.
The internal divisions had more a play into this than anything else, Windows could have evolved into something like Android or Inferno, but that isn't something that those on Sinofsky's team would accept.
Also why we got WinRT being like .NET, but with COM and C++, with .NET Native being a complete difference compiler toolchain, as he got hold of the Windows reigns.
Because it was yet another all-in, where all future Microsoft software was going to be .NET based, but WinDev/Office never played ball.
We just have to go back in time and see all those Visual Studio.NET shows on surviving documents, or how Ext-VOS (what became .NET) was being done at MSR.
We could have had something like Android, Inferno/Limbo in terms of .NET usage across the Windows layers, but it always bumps into the love for COM and C++, which incendently is how many Longhorn ideas were remade in Vista and continues to this day, using COM instead of .NET.
One design iteration already has a working, implemented branch available, it’s just one of the hardest designs to get right, to remain backwards compatible, to have it work nice with generics and all the other features, etc.
So once they actually settle on a design (which they seem to have closed on quite a lot in the last couple of years), it might not take that long to happen.
Noting that Valhalla value types are about guaranteeing object value identity with memory layout and/or flattening supposedly deriving from that.
Modeling unmanaged sequence of bytes within the type system (like receiving a typed buffer from un managed code) might still be challenging
1. Pointers to the same (and not just references to objects).
2. Unions (via explicit-layout structs)
3. Function pointers.
4. C-style varargs.
To be fair, not all of these have been exposed in C# historically even though CLR had them all along. Most notably, unmanaged function pointers took over 20 years. And since most people look at CLR through the prism of C#, they aren't necessarily aware of these features.
Still, one way or the other, we're at the point where pretty much any C program can be transpiled to C# in a one-to-one mapping of almost every construct (setjmp/longjmp has to be emulated with exceptions), and a very similar performance profile of the resulting code.