Phillip Carter
Phillip Carter
Right, but by being semantically equivalent to a byref, they're supported as returns. I think this is something that can be reconsidered, but I don't think this was an oversight.
cc @NTaylorMullen - this sounds like more motivation to use the .NET runtime dependencies extension
FYI this is now a feature supported in Rider 2019.1: https://twitter.com/resharper/status/1123199669025280001
Tagging https://github.com/dotnet/fsharp/issues/4924 and using this as a canonical sub-problem of that issue https://github.com/dotnet/fsharp/issues/4924#issuecomment-390406522 for more information
I think this is expected. In your code, you're telling the compiler to infer to the types for `plus'` and there are two candidates that could satisfy the constraint. It...
Sure, there might be a bug in here. But the mixing of overloads, SRTP, and inference is so complex that it's just unsurprising that a seemingly unintuitive result would get...
cc @KevinRansom
Tracking as a bug as the key thing - explicitly referencing an older FSharp.Core that is compatible with this framework - should work.
This error is to be expected - no longer making `x` an `inref` would violate guarantees around not copying, so an explicit copy is needed if that is your aim....
The 'this' pointer is an `inref` from the F# type system standpoint. This was introduced in F# 4.5 to ensure certain guarantees around copying and structs, which is why this...