fslang-design VS corert

The C# compiler got a ton of new smarts around reference type nullability and almost all of the BCL (.NET standard library) got annotated for it. I don't know when F# will finally pick up all the new compile-time smarts for Nullable Reference Types, but it has been proposed and prototyped, at least [1].

[1] https://github.com/fsharp/fslang-design/blob/main/RFCs/FS-10...

Note: For some reason I cant submit the Url with the specific section of the Drawbacks section, but it is here https://github.com/fsharp/fslang-design/blob/main/FSharp-7.0...

Does type provider still only support literal strings for definition, right? Supporting records could make it feasible to create something really good as just a side project. I remember suggestions to allow taking record/types but can't find the gh issue or related. Found the rfc. Seems abandoned. It could be a game changer. :(

But, when I try this example from the RFC, I get an "expected option but here has type voption" error.

Add insert/remove/update functions for collections, also Keys/Values for Map

This is https://github.com/fsharp/fslang-design/blob/main/RFCs/FS-1079-union-properties-visible.md

Someone writes an RFC about the approved-in-principle suggestion with more details and opens a pull request to https://github.com/fsharp/fslang-design.

An explanation of the problem: https://github.com/dotnet/corert/blob/master/Documentation/u...

Memory was not really designed for having lots of instances of it and doing intensive computations/searches on the instances. The reason for it is that Memory.Span property is actually quite expensive to call. Memory is a union type for storing strings, arrays, and even handles to native memory. Every time you construct it , slice it, or retrieve it's span, lost of machinery related to this union has to run. For example see the source for the Memory.Span property: https://github.com/dotnet/corert/blob/master/src/System.Private.CoreLib/shared/System/Memory.cs#L285.

For earlier versions, try https://github.com/dotnet/corert

Yeah I know it's slower on its own, but I was sure it was handled as a faster intrinsic by the runtime. Went to double check and realized I was actually mixing things up with what CoreRT did (see here) but I guess it doesn't apply to CoreCLR. Would be surprised if there weren't any specific optimizations for this with .NET 6+ though, or at the very least with NativeAOT (given they've been porting some bits over from CoreRT and .NET Native too). Will need to go gather more info on this, as it's pretty interesting 🙂

> AOT compilation? I'll believe it when they'll release it, until then, it's all speculation

Devil's in the details, but there -is- AOT compilation[0]. While it hasn't been released as an official product, it has been used for a few projects including a commercial game [1]. And yes, they're looking into the next steps to make it a 'released' thing.[2]

[0] - https://github.com/dotnet/corert/

[1] - https://github.com/dotnet/corert/issues/8233#issuecomment-65...

[2] - https://github.com/dotnet/runtimelab/tree/feature/NativeAOT

That is a well known issue, also what prevented F# to be properly used in .NET Native.

https://github.com/dotnet/corert/issues/5780#issuecomment-40...

CoreRT