Should we allow switch on generic?

[Thaina]

T Parse<T>(string s)
{
    switch(T)
    {
        case string:
            return s; // could assume type in the specific block
        case int:
            return int.Parse(s);
        case long:
            return long.Parse(s);
        case float:
            return float.Parse(s);
        case double:
            return double.Parse(s);
        case MyCustomClass:
            return new MyCustomClass(s);
        case MyCustomStruct:
            return new MyCustomStruct(s);
        case class: // is it possible?
            return null;
        default:
            return default(T);
    }
}

[YairHalberstadt]

I commonly have this case, and I need to do the horrific

switch (typeof(T))
{
    case var t when t == typeof(string):...
    case var t when t == typeof(int):...
}

However my preferred solution would be switching on type which is already a proposal. #356. I feel this makes more sense conceptually than switching on a type parameter

[ufcpp]

#356 ?

[Thaina]

@YairHalberstadt @ufcpp I already did case var t where t == typeof(SomeType) already but there was 2 points. It can't infer inheritance. And it can't infer return type (but this might not be possible)

T Parse<T>(object s)
{
    switch(typeof(T))
    {
        case typeof(string):
            return s; // Error, must use `return (T)s;` or `return (T)((object)s)`
//...
        default:
            return default(T);
    }
}

I wish that

T Parse<T>(object s)
{
    switch(T)
    {
        case string:
            return s; // No error
//...
        default:
            return default(T);
    }
}

And it also more verbose that we need to typeof everywhere. Even the type inference is not possible I think this syntax is still better

[YairHalberstadt]

@Thaina

Currently the language has no concept of inferring the type of a generic type parameter.

If it did, maybe the following ought to work as well:

T M(T t)
{
   if (t is string s) //T is a supertype of string
       return "hello + s";
}

For example.

However I think that is a much bigger feature than just switching on T, and I'm not sure the benefits are significant enough to make it worth it.

[reflectronic]

1. I don't think there's a way to express this (especially matching on class etc.) in IL without calling into reflection, although we already have prior precedent to doing this with new T().
2. If we do this, it should be extended generally to patterns (so you can do, for example, if (T is string).

[YairHalberstadt]

@reflectronic

Whilst technically it does call into reflection, it should only need the Type APIs , which are very fast, so I don't think that should be a problem.

[DavidArno]

What would be useful for me on occasions is the ability to use switch with generics in the following way:

class C<T1, T2>
{
    private T1 _t1;
    private T2 _t2;

    public T GetValueOf<T>()
        => T switch {
            T1 => _t1,
            T2 => _t2,
            _ => throw new InvalidOperationException()
        };
}

such that eg in the first branch, the compiler knows that T is the same type as T1, so no cast is required of _t1 to T.

However, I suspect this is real edge-case stuff and that the ROI of implementing it would be low.

[ufcpp]

In such a edge case, Unsafe.As is enough, IMO.

class C<T1, T2>
{
    private T1 _t1;
    private T2 _t2;

    public T GetValueOf<T>()
    {
        if (typeof(T) == typeof(T1)) return Unsafe.As<T1, T>(ref _t1);
        if (typeof(T) == typeof(T2)) return Unsafe.As<T2, T>(ref _t2);
        throw new InvalidOperationException();
    }
}

[DavidArno]

@ufcpp,

I've taken to using an extension method:

public static T ItemAs<T>(this object? obj)
    => obj is T cast 
        ? cast 
        : throw new InvalidOperationException($"Failed to cast item to type {typeof(T)}");

and then using it like:

public T GetValueOf<T>()
    => T switch {
        var t where t == typeof(T1) => _t1.ItemAs<T1>(),
        var t where t == typeof(T2) => _t2.ItemAs<T2>(),
        _ => throw new InvalidOperationException()
    };

It's easy to work around. It just feels clunky. But in SuccincT, which uses generics far far more than I've ever used it before, there's along around a dozen such cases, even there. So it's a serious edge case and I'll live with the remaining clunkiness if/when #356 is implemented.

[ufcpp]

The Unsafe.As can avoid boxing for value types while the ItemAs can not.
Anyway, there exists work around.

[Thaina]

@ufcpp There are always exist a workaround for new syntax such as "Always alloc then don't forget to call init so we don't need new keyword"
But we still use new anyway