Add RFC-1092 for support of System.Half #499
Conversation
See language suggestion: fsharp/fslang-suggestions#909
| * We should take proper measures to allow FSharp.Core to be linked with other versions of .NET that do not have this type. | ||
|
|
||
|
|
||
| # Unresolved questions |
There was a problem hiding this comment.
The chief unresolved question for me is that because this type is only available in .NET 5 and higher, we'll need to understand the best way to expose the type alias. Referencing it as System.Half is fine as that will all work according to your environment. But since type abbreviations in FSharp.Core are ultimately orthogonal, we'll have to figure it out.
There was a problem hiding this comment.
I agree, I put that in the discussion thread too. For this and future dependencies on features added to net core or NetStandard, we need perhaps some bespoke way to implement that in FSharp.Core so that it can still be used interchangeably with older versions too.
|
|
||
| # Drawbacks | ||
|
|
||
| If we don't do this, people could still use `System.Half` directly, but don't have good language support, like overloaded conversion functions and proper compilation to IL. |
There was a problem hiding this comment.
I would like to understand the current experience of using System.Half and see a comparison of what does and doesn't work when the user simply defines an alias type half = System.Half.
My belief is the experience won't be that bad but some conversions will be missing, as will a half function.
I don't know of anything that falls under the "proper compilation to IL" category.
We should be precise about the current experience.
There was a problem hiding this comment.
@dsyme It's been a while, but the current experience is indeed not too bad. Though users do not have formatters in sprintf and the like, nor do they have any ability for creating constants. The latter might actually be made possible if we were to allow constants of any blittable type (???).
I doubt System.Half is widely used presently. It's main use case is in CUDA and AI programming.
While I'd like this feature (and Int128, for that matter), unless we find a way to support features from .NET 6.0 and up, I don't quite see this happening: #500 (comment).
|
Will need to switch to RFCS-1094 or something due to erased unions grabbing the number |
|
One more thing for the design section - |
See language suggestion: fsharp/fslang-suggestions#909 and discussion for this RFC: #500.