remove prohibition of unmanaged constructed types

[RexJaeschke]

No description provided.

[BillWagner]

rebased on the latest draft v8 branch on 9/26/2023

[BillWagner]

This LGTM @RexJaeschke

I'm happy to merge at the next meeting.

[jskeet]

The title talks about unmanaged constructed types - the text seems to be about pointer types. (It looks like constructed types still count as managed.)
I think I need a bit more context to understand this change.

[BillWagner]

Added one possible suggestion.

[BillWagner]

Suggested update (Assuming the type parameter must have the unmanaged constraint):

Suggested change

	- Any user-defined *struct_type* that is not a constructed type and contains instance fields of *unmanaged_type*s only.
	- In unsafe code ([§23.2](unsafe-code.md#232-unsafe-contexts)), any *pointer_type* ([§23.3](unsafe-code.md#233-pointer-types)).
	- Any user-defined *struct_type* that contains instance fields of *unmanaged_type*s or where all arguments for all type parameters in a closed constructed types are of *unmanaged_type*s only.
	- In unsafe code ([§23.2](unsafe-code.md#232-unsafe-contexts)), any *pointer_type* ([§23.3](unsafe-code.md#233-pointer-types)).

[Nigel-Ecma]

It is not clear that the unmanaged constraint is required, just that the provided type is unmanaged.

Have fun with the below:

• With the where clause the current VS set to 8.0
  • rejects the 3rd & 4th CheckUnmanaged() calls at compile time – they are not unmanaged types
  • accepts the second even though there is no unmanaged constraint on Coords<>
• However take out the where and it runs and reports only one of the types is managed, which is a little worrying! But then I copied the test code from StackOverflow…

using System;
using System.Collections.Generic;
using System.Reflection;

namespace UnmanagedConstructed
{
    public struct Coords<T>
    {
        public T X;
        public T Y;
    }

    public static class UnmanagedTypeExtensions
    {
        // U and IsUnmanaged copied from StackOverflow...
        class U<T> where T : unmanaged { }
        public static bool IsUnmanaged(this Type t)
        {
            try { typeof(U<>).MakeGenericType(t); return true; }
            catch (Exception) { return false; }
        }
    }

    public class UnmanagedTypes
    {
        public static void Main()
        {
            CheckUnmanaged<int>();
            CheckUnmanaged<Coords<int>>();
            CheckUnmanaged<object>();           // invalid if below where clause is uncommented
            CheckUnmanaged<Coords<object>>();   // ditto
        }

        private static void CheckUnmanaged<T>() // where T : unmanaged
        {
            Console.WriteLine($"{typeof(T)} is {(typeof(T).IsUnmanaged() ? "unmanaged" : "managed")}");
        }
    }
}

[jskeet]

After discussion, we agree with Nigel's analysis, and think we don't need to refer to type parameters, but we want an example (potentially like Nigel's, but simpler - just the method with an unmanaged constraint).

[BillWagner]

@jskeet Is someone assigned to create the example? (I can't remember from the last meeting)

[jskeet]

@BillWagner: Me - the example along with the other changes to this PR. If I can just find the time...

[jskeet]

I've been having another look at this, and trying to get my head back into where we were in May... and I've failed. I'll mark this as "meeting discuss" again to see if we can get it right together during the next meeting.

I think there's some subtlety around type parameters though - because a type parameter with no constraints won't count as as unmanaged, but a type parameter with the unmanaged constraint will:

class Program
{
    static void Main()
    {
        Check1<int>();
        Check2<int>();
    }

    static void Check1<T>()
    {
        CheckUnmanaged<T>(); // Error, because T *might* not be unmanaged
    }

    static void Check2<T>() where T : unmanaged
    {
        CheckUnmanaged<T>();
    }

    static void CheckUnmanaged<T>() where T : unmanaged
    {
    }
}

[Nigel-Ecma]

One comment added in context as its in the range of the changes.

Lines 515, 617 & 699 probably also need to be changed. Also need to consider the unmanaged_type grammar (line 693), should it now allow a type parameter with the unmanaged constraint?

[Nigel-Ecma]

It is not clear that the unmanaged constraint is required, just that the provided type is unmanaged.

Have fun with the below:

• With the where clause the current VS set to 8.0
  • rejects the 3rd & 4th CheckUnmanaged() calls at compile time – they are not unmanaged types
  • accepts the second even though there is no unmanaged constraint on Coords<>
• However take out the where and it runs and reports only one of the types is managed, which is a little worrying! But then I copied the test code from StackOverflow…

using System;
using System.Collections.Generic;
using System.Reflection;

namespace UnmanagedConstructed
{
    public struct Coords<T>
    {
        public T X;
        public T Y;
    }

    public static class UnmanagedTypeExtensions
    {
        // U and IsUnmanaged copied from StackOverflow...
        class U<T> where T : unmanaged { }
        public static bool IsUnmanaged(this Type t)
        {
            try { typeof(U<>).MakeGenericType(t); return true; }
            catch (Exception) { return false; }
        }
    }

    public class UnmanagedTypes
    {
        public static void Main()
        {
            CheckUnmanaged<int>();
            CheckUnmanaged<Coords<int>>();
            CheckUnmanaged<object>();           // invalid if below where clause is uncommented
            CheckUnmanaged<Coords<object>>();   // ditto
        }

        private static void CheckUnmanaged<T>() // where T : unmanaged
        {
            Console.WriteLine($"{typeof(T)} is {(typeof(T).IsUnmanaged() ? "unmanaged" : "managed")}");
        }
    }
}

[jskeet]

(@jskeet to have another pass at this - in this PR.)

[jskeet]

And look for other places, e.g. 515.

[jskeet]

Also (try to) remove the grammar as type parameters can be unmanaged - instead, make references to it specify that the type must be unmanaged. (Do this in a separate commit.)

[jskeet]

We should talk about this again - I'm finding it hard to get my head back into it, so when we talk, let's make verbose notes.