[WIP] Unmanaged constructed types

[TIHan]

Matching C#'s feature: dotnet/csharplang#1937

Allows generic structs to be 'unmanaged' at construction if it can determine to be so.

A few examples:

[<Struct>]
type S<'T, 'U> =

    [<DefaultValue(false)>] val X : 'T

let test (x: 'T when 'T : unmanaged) = ()

let passing () =
    test (S<float, int>())

let passing2 () =
    test (S<float, obj>()) // passes as the 'obj' type arg is not used as part of the backing field of a struct

let passing3<'T when 'T : unmanaged> () =
    test (S<'T, obj>())

let not_passing () =
    test (S<obj, int>())

let not_passing2<'T> () =
    test (S<'T, obj>())

Another example:

[<Struct>]
type S<'T> =

    val X : 'T

    new (x) = { X = x }

let test (x: 'T when 'T : unmanaged) = ()

let passing () =
    test (S(1))

let not_passing () =
    test (S(obj()))

Example on nested generic structs:

[<Struct>]
type W<'T> = { x: 'T }

[<Struct>]
type S<'T> = { x: W<'T> }

let test (x: 'T when 'T : unmanaged) = ()

let passing () =
    test Unchecked.defaultof<S<int>>

let not_passing () =
    test Unchecked.defaultof<S<obj>>

Remaining work:

• Tests
• Emit IsUnmanagedAttribute on type arguments with the 'unmanaged' constraint for interop.
• Consume type arguments from .NET assemblies that have the IsUnmanagedAttribute to mean they have the unmanaged constraint. This is also for interop.
• Support anonymous struct records
• Support struct unions
• Fix struct tuples

Regarding the struct tuples, this works:

let passing () = 
    let x = struct(1, 2)
    test x

But this doesn't:

let not_passing () = 
    test (struct(1, 2))

After some debugging, it looks like at the point where isUnmanagedTy gets called, the type arguments for the tuple haven't been solved yet which seems weird to me; this is a separate bug in the type system.

[dsyme]

You should almost never match on TType directly - always use tryAppTy (note, tryDestAppTy should really be called tryTcrefOfAppTy)

[dsyme]

The reason you should never match on TType is that it might be a solved type variable or a type abbreviation, both of which get expanded by tryAppTy and friends

[TIHan]

That's fair. I thought it was fine considering we were stripping eqns anyway.

[dsyme]

Yes, you're correct

[dsyme]

You can remove the comment, the code is fine perf wise

[TIHan]

Ok. For what it was worth, I did do some perf testing on it. I think the number was 15ms if it was called 10 thousand times, which the only way for that to happen is to have 10 thousand written calls that test the unmanaged constraint.

[dsyme]

The code is a little odd. Normally we would not enforce the transitive constraints like this - we would require that each type parameter itself has the unmanaged constraint, e.g. consider this:

    [<Struct>]
    type C1<'T when 'T : unmanaged> = 
        ...

    [<Struct>]
    type C2<'U when 'U : unmanaged> = 
        ... field C1<'U> ....

Then when checking whether C2<int> is unmanaged we would check whether the instantiated field type C1<int> is unmanaged. It looks like you're re-implementing substitution here.

What if you use simply this:

            elif tycon.IsStructOrEnumTycon then
                let tinst = mkInstForAppTy g ty
                tycon.AllInstanceFieldsAsList |> List.forall (fun r -> isUnmanagedTy g (actualTyOfRecdField tinst r))

[dsyme]

Note that actualTyOfRecdField gets the instantiated field type under a governing instantiation derived from ty

[TIHan]

actualTyOfRecdField is exactly what I need and will simplify the existing code; I was reimplementing substitution. I had a hard time trying to find such a function before.

[dsyme]

I'd like to consider how to make it easier to find the things in TastOps.fs. Making them all instance extension methods on the various primary types would be one option.

[dsyme]

Looks like the added code could be simpler

[TIHan]

Not much progress on this yet. Still need to create a RFC. I don't see much progress happening soon as it's not a priority, unless someone is truly blocked by not having this feature.

[zpodlovics]

Native interop and representation is a long awaited[1] and critical functionality especially for [2]. It may seems a low hanging fruit, however performance (and correctness) is a feature now, as the cloud/on-prem cost will be roughly proportional to the performance.

[1] fsharp/fslang-suggestions#493
[2] dotnet/spark#41 (comment)

[zpodlovics]

Any update on this? Performance (and correctness) is a must have feature now, as the cloud/on-prem cost will be roughly proportional to the performance.

[cartermp]

This isn't a priority for us at the moment, but we're happy to accept contributions from interested parties.

[vzarytovskii]

I’ve added an RFC for it: fsharp/fslang-design#480

[vzarytovskii]

Closing this one, gonna open new one on top of latest main.