FSharp.UMX no longer compiles on .NET 7

Repro steps

Install .NET SDK 7.0.100-preview.4.22175.1 or newer and run this in fsi

[<MeasureAnnotatedAbbreviation>] type Guid<[<Measure>] 'm> = System.Guid

Expected behavior

Compiles.

Actual behavior

error FS3360: 'Guid<'m>' cannot implement the interface 'IComparable<_>' with the two instantiations 'IComparable<Guid>' and 'IComparable<Guid<'m>>' because they may unify.

Known workarounds

Downgrade to 7.0.100-preview.2.22103.2.

[dsyme]

Notably we do have C# tests (and in some cases IL tests) covering the impact of startup, devirtualization, casting, type checks, etc.

My concern is compilation performance (and in particular type inference and name resolution performance both in compiler and in IDE, i.e. any logic in toolchains that involves walking the hierarchy of interfaces looking at metadata along the way). For example a compiler might search the hierarchy for, say IDisposable, or IEnumerable, or might search for name resolutions. All of this will be at least slightly impacted in some scenarios - more information, more cost - but it’s unclear to me if there’s any critical case where this occurs on a main path for compilation.

The performance of generated code is not a concern I have, I’m sure you’ll look after that.

[dsyme]

If there are specific suggestions on tweaks we could make …

I don’t have any concrete suggestions - Generic math is basically a bottomless quagmire of complexity as more and more dimensions of the problem are considered - and what you have is already at the upper limit of any reasonable complexity boundary - adding unitization would be many bridges too far.

As you’ve mentioned, .NET 7 uses explicit-declaration-of-traits-via-interfaces (rather than, say, implicit trait instances arising from the declarations themselves, as in SRTP), and expresses those declarations using the existing C# and IL interfaces. It is just not possible to properly support unitized types within those limitations (without adding higher-kinded types at very least - and all the complexity that comes with using that).

For example of why higher-kinded typed would be needed - IMultiplyOps would have to become (in C# syntax)

interface IMultiplyOps<UnitizableType1, UnitizableType2, UnitizableType3>
{
    UnitizableType3<Unit1*Unit2>  op_Multiply<Unit1, Unit2>(UnitizableType1<Unit1> x, UnitizableType2<Unit2> y)
}
struct Double<Unit>: IMultiplyOps<Double<_>, Double<_>, Double<_>>
{
    Double<Unit1*Unit2>  op_Multiply<Unit1, Unit2>(Double<Unit1> x, Double<Unit2> y)
...
}

Note

• The unit-friendly versions of op_Multiply must be generic in the units
• UnitizableType1 etc are all higher-kinded
• Unit1*Unit2 is some imagined C# syntax for the multiplication of two units (kg * m for example).
• Double<_> is some imagined C# syntax for instantiating a thing taking a higher-kinded type
• A similar story plays out for some other operations.

Anyway none of this is expressible within .NET or C# or F#.

I think on the whole we just won’t worry about this. F# will still play nicely enough with the non-unitized hierarchy you have and the type inference will work well. We’ll just make it clear that there are limitations when combining the feature with units of measure.