Feature request: C# 7.3 enum generic constraint not being able to cast to integer

[alexdrl]

I am not being able to cast a generic method restricted type parameter to work like I supposed it worked.

public void DoSomething<T>(List<T> list)
    where T : Enum
{
    T first = list.FirstOrDefault();
    int value = (int) first;
}

I am missing something?

UPDATE:
What about something like:

public void DoSomething<T>(List<T> list)
    where T : Enum, int
{
    T first = list.FirstOrDefault();
    int value = (int) first;
}

[Joe4evr]

It's not guaranteed the enum backing field is an int. What are you gonna do if it's a ulong, for example?

[alexdrl]

I thought about that, what about something like this:

public void DoSomething<T>(List<T> list)
where T : Enum, int
{
T first = list.FirstOrDefault();
int value = (int) first;
}

[YairHalberstadt]

You could force it with dynamic:

public void DoSomething<T>(List<T> list)
where T : Enum
{
T first = list.FirstOrDefault();
int value = (dynamic) first;
}

Which actually gets compiled to:

public void DoSomething<T>(List<T> list)
where T : Enum
{
T first = list.FirstOrDefault();
int value = (int) (object) first;
}

[alexdrl]

In my code I solved it casting the Enum as an object and to int... I suppose that this could incur in object casting and performance cost. Will dynamic be more performant?

Thanks for the suggestion, but not having to do this tricks would be ideal.

[YairHalberstadt]

It gets compiled to identical code in this case. The real cost here is of course boxing and unbocing, not casting which is essentially free.

If this is really performance critical you could use unsafe code, or even call System.Runtime.CompilerServices.Unsafe.As<TFrom, TTo>, which would avoid boxing

[mikernet]

I recall reading that in .NET 4.something the boxing/unboxing gets optimized out by the JIT in generic methods.

[mikernet]

Nevermind, scratch that. Possible future optimization?

For this method:

int GetValue1<T>(T value)
{
    return (int)(object)value;
}

The JIT is smart enough to optimize out the box/unbox if T is an int because the types match exactly, but unfortunately it isn't smart enough to do it if T is a compatible enum type 👎

[ufcpp]

using System;
using System.Runtime.CompilerServices;

public static class EnumExtension
{
    // size-specific version
    public static TInt AsInteger<TEnum, TInt>(this TEnum enumValue)
        where TEnum : unmanaged, Enum
        where TInt : unmanaged
    {
        if (Unsafe.SizeOf<TEnum>() != Unsafe.SizeOf<TInt>()) throw new Exception("type mismatch");
        TInt value = Unsafe.As<TEnum, TInt>(ref enumValue);
        return value;
    }

    // long version
    public static long AsInteger<TEnum>(this TEnum enumValue)
        where TEnum : unmanaged, Enum
    {
        long value;
        if (Unsafe.SizeOf<TEnum>() != Unsafe.SizeOf<byte>()) value = Unsafe.As<TEnum, byte>(ref enumValue);
        else if (Unsafe.SizeOf<TEnum>() != Unsafe.SizeOf<short>()) value = Unsafe.As<TEnum, short>(ref enumValue);
        else if (Unsafe.SizeOf<TEnum>() != Unsafe.SizeOf<int>()) value = Unsafe.As<TEnum, int>(ref enumValue);
        else if (Unsafe.SizeOf<TEnum>() != Unsafe.SizeOf<long>()) value = Unsafe.As<TEnum, long>(ref enumValue);
        else throw new Exception("type mismatch");
        return value;
    }
}

[yaakov-h]

@ufcpp how about unsigned? 😄

[YairHalberstadt]

@ufcpp
Shouldn't some of those != be ==?

[ufcpp]

@yaakov-h
This checks only size of the TEnum, thus byte and sbyte are the same.

@YairHalberstadt
Mistake. == is correct.

[mikernet]

It gets compiled to identical code in this case.

@YairHalberstadt Wait a sec...it definitely does not. That dynamic cast can't possibly compile to the identical code above. Written the way you have it:

int value = (dynamic) first;

That line of code needs to look for an implicit conversion between whatever type first is (and to dynamic it's just an object until it calls GetType()) to int.

Even if you add an explicit cast there's still no way it emits the same code. The explicit dynamic cast will work fine for something like a byte sized enum being cast to an int, but casting a byte sized enum stored in an object to int definitely doesn't work.

This all involves dynamic call site binding if you start using dynamic.

[YairHalberstadt]

@mikernet
Take a look at sharplab

[mikernet]

@YairHalberstadt Look at the IL view in SharpLab. That's not the code that gets emitted. It's decompiler either has a bug or intentionally changes the code, but that's not what actually gets emitted and the performance of the emitted code isn't the same as it's decompiled view.

[mikernet]

Your dynamic method doesn't even work - it throws a RuntimeBinderException: Cannot implicitly convert type 'UserQuery.Test' to 'int'. An explicit conversion exists (are you missing a cast?)

(UserQuery.Test is an int backed enum)

[mburbea]

Have you considered GetHashCode? Which while kind of a strange workaround guarantees to get back an int, even if the backing type is not an integer.
According to this issue, it doesn't box:: https://github.com/dotnet/coreclr/issues/8143

[svick]

@mburbea GetHashCode is guaranteed to give you an int, but there is no guarantee about which int it will give you, so I think using it here is a bad idea.

[mikernet]

@ufcpp Yes I know. The only additional overhead my method has is a generic cached delegate invocation which is why it runs at almost the same speed. 10 million conversions using your method took 19ms, mine took 27ms. I know Unsafe.As is fast, that's why I wanted to see how mine compared to it and I'm rather happy with the results, can't do much better than that 😄

[mburbea]

@svick, sure, but if you're blindly assuming that the type is an int. Are you really concerned? If the type isn't long or ulong, you'll get the desired result.

This is still safer than the suggested Unsafe.As.

[mikernet]

@mburbea Just because Unsafe.As was used doesn't mean it it's actually unsafe. The way it's written looks pretty safe to me. Care to point out a situation where it wouldn't be?

There's always my solution if you don't like unsafe code :)

[mburbea]

Sorry, I retract my objection. That Unsafe.As is perfectly fine. I was assuming it was just blindly using UnsafeAs, but that solution is safe and should produce good quality code.

[Ultrahead]

@alexdrl: maybe you could define a converter (?):

        public static class EnumConverter<TInput, TOutput> 
            where TInput: struct, Enum
            where TOutput : struct, IConvertible
        {
            public static readonly Func<TInput, TOutput> Convert = GenerateConverter();

            private static Func<TInput, TOutput> GenerateConverter()
            {
                var parameter = Expression.Parameter(typeof(TInput), typeof(TInput).Name);
                var dynamicMethod = Expression.Lambda<Func<TInput, TOutput>>
                (
                    Expression.Convert(parameter, typeof(TOutput)),
                    parameter
                );
                return dynamicMethod.Compile();
            }
        }

And then you could call it either directly or define an extension method for the specific enum type you want to cast to int:

        public static int ToInt(this MySpecificEnum source)
        {
            return EnumConverter<MySpecificEnum, int>.Convert(source);
        }

[mariangemarcano]

Another option based on @Ultrahead suggestion, limited to int and adding some extra checks to prevent silent errors, making sure that the type does not convert to the wrong value, and throwing an exception if the value is not defined by enum.

  public static class EnumConverter<TInput>
        where TInput : struct, Enum
    {
        private static readonly Func<TInput, int> _convertFrom = GenerateConverter<TInput, int>();
        private static readonly Func<int, TInput> _convertTo = GenerateConverter<int, TInput>();

        private static Func<TInput, TOutput> GenerateConverter<TInput, TOutput>()
        {
            var parameter = Expression.Parameter(typeof(TInput), typeof(TInput).Name);
            var dynamicMethod = Expression.Lambda<Func<TInput, TOutput>>
            (
                // Make sure the type is not silently converted to a wrong value (overflow)
                Expression.ConvertChecked(parameter, typeof(TOutput)),
                parameter
            );
            return dynamicMethod.Compile();
        }

        /// <summary> Converts a generic Enum to int </summary>
        public static int AsInt(TInput input) => _convertFrom(input);

        /// <summary> Converts from int to generic Enum type </summary>
        public static TInput AsEnum(int input)
        {
            var result = _convertTo(input);

            if (!Enum.IsDefined(typeof(TInput), result))
                throw new ArgumentOutOfRangeException("Value is not defined in the enum.");

            return result;
        }
    }

[alexdrl]

@Ultrahead I do not need the initial code anymore, and your code needs to know in advance that the enum is an integer.

What I initially proposed is that the compiler supported the additional compiler check that the enum passed to the generic method has an underlying specific type (int, ulong...). So that my compile Will not compile if the passed enum does not have the specfied type.

Thank you for your comments, I have learned a lot about .NET performance internals.

[Ultrahead]

Alejandro: es bueno saberlo. I posted the code as a workaround, though, given its performace (it avoids boxing).

I didn't see the proposal, besides the title it-self. Because even in the case you present, the compiler should know in advance your intent. Maybe a way to clearly state should be allowing something like:

where T: Enum, int

[alexdrl]

I didn't see the proposal, besides the title it-self. Because even in the case you present, the compiler should know in advance your intent. Maybe a way to clearly state should be allowing something like:

where T: Enum, int

@Ultrahead Yes, If the compiler knows the underlying type, why not having the possibility to use it as a generic method constraint? Or the compile does not know the underlying type for an enum?

Maybe I should rephrase the issue title.

[Ultrahead]

It does know but it's a matter of specifying your intent in the signature to guarantee and enforce compilation. That's why I mentioned:

where T: Enum, int

or even T: Enum(int)

The title is ok.

[mikernet]

There are probably a couple places I would use this if it was available since a compile time error is much nicer than a runtime error if you require an enum of a certain underlying type but that's such a niche situation that I can't imagine this will get a lot of priority.

[mikernet]

Syntax wise I would imagine it would have to be more like the second example @Ultrahead gave because it's not actually an int so the other way would be very misleading.

[Ultrahead]

@mikernet: yes, I realized that after posting the first syntax. I agree.