Proposals: generics, operators and other

[denis-kudelin]

deleted

[yaakov-h]

1. Exploration: Shapes and Extensions #164
2. Champion "Allow System.Delegate as a constraint" (15.7) #103 / Champion "Allow System.Enum as a constraint" (15.7) #104
3. Not sure.
4. Has been discussed in a few places, but not had much support.
5. Has been discussed in a few places, but not had much support.
6. I think is new, but what’s the point?
7. Proposal: memberof operator keyword #712

[denis-kudelin]

6. I think is new, but what’s the point?

The point is that it sometimes could help during debugging to find the source faster without need to use inner exceptions and changing exception type/reference if I don't want it. For example, I'm using it in expressions:

                try
                {
                    return someCompiledExpression.DynamicInvoke(item);
                }
                catch (TargetInvocationException ex)
                {
                    (ex.InnerException ?? ex).ReThrow(); // Actually, there is already some way to reach it.
                    throw;// just in case :)
                }

Also sometimes I want to rethrow the exception in another thread what waits some result and no need to check inner exceptions every time that simplifies exception constraints.

[orthoxerox]

Number 3 is #339

[benaadams]

You can do 6 with ExceptionDispatchInfo

try
{
    return someCompiledExpression.DynamicInvoke(item);
}
catch (TargetInvocationException ex)
{
    ExceptionDispatchInfo.Capture(ex.InnerException ?? ex).Throw();
}

[yaakov-h]

@benaadams you often need a dummy return or throw after EDI.Throw, because the compiler doesn’t know that EDI.Throw does not return.

[benaadams]

This is true 😢

[denis-kudelin]

You can do 6 with ExceptionDispatchInfo

@benaadams Already did long time ago 😄

@yaakov-h

@benaadams you often need a dummy return or throw after EDI.Throw, because the compiler doesn’t know that EDI.Throw does not return.

Yes, you even can see it in my example. My current implementation works so:

[DebuggerStepThrough]
public static Exception ReThrow(this Exception ex) => ExceptionDispatchInfo.Capture(ex).Throw(); // my custom ExceptionDispatchInfo
//usage
throw exception.ReThrow() //throw operator is only for the compiler

Would be nice to have rethrow operator..

[CyrusNajmabadi]

Sorry for the bunch of proposals in one topic, not sure that I need to create so much ones.

@DenisKudelin Thanks for all the passion and enthusiasm here. But for the future, could you please make unique proposals for each suggestion. Having them all be in one issue will effectively make it very difficult to actually keep track of the individual topics. Thanks!

[denis-kudelin]

@CyrusNajmabadi ok, I just decided to avoid many duplicates with 2.5 lines description, if some ideas are good, I could create separate proposals.

[Joe4evr]

Rethrow operator for saving the original stacktrace

throw; does this since like C# 4 or whatever.

[denis-kudelin]

@Joe4evr please, read comments above.

[aluanhaddad]

1. Casting to a generic class/interface/struct without specifying generic types + ability to call its non-generic methods without using interfaces:

    class Foo<T, U>
    {
        public bool Test() => true;
        public T GenericFoo() => default(T);
        public void GenericFoo(T value) { }
    }
    
    object obj = new Foo<int>();
    ((Foo<,>)obj).Test(); //GenericFoo methods of class Foo<,> should not be available in this case.
    Foo<,> foo = (Foo<,>)obj;
    ((Foo<int,byte>)foo).GenericFoo()

In the provided example, it is not clear what Foo <,> represents.
Also, that a method signature does not refer to the enclosing generic type parameters does not indicate that its implementation does not depend on them.

Also, and I'm admittedly nitpicking, the terminology is not correct. Specifically, there are no generic methods in the example.

[bondsbw]

@aluanhaddad

Also, that a method signature does not refer to the enclosing generic type parameters does not indicate that its implementation does not depend on them.

There is no type leakage, in the same way that it could implement interfaceIFoo with no generic type parameters which contains member bool Test();.

[bondsbw]

@DenisKudelin Could you explain what you expect this to do?

class Foo<T<U>>

[denis-kudelin]

@bondsbw

@DenisKudelin Could you explain what you expect this to do?

class Foo<T>

We can use any generic class with one parameter as the generic parameter of Foo<>

new Foo<Predicate<byte[]>>()

I've come across enough cases where I actually need it (as well as numbers 1 and 7)

[DavidArno]

@bondsbw,

I too can think of situations where Foo<T<U>> would be useful. Currently, I work around the lack of such a construct via:

interface IBar<T>{}
class Foo<T, U> where T : IBar<U> {}

and then have every type that I'm going to use as T<U> in Foo implement IBar. It works, but it's makes for really messy generic types once more than one type parameter is used. For example, a genuine type in my code:

IFuncWithHandler<IFuncMatcher<T1, T2, T3, T4, TResult>, T1, T2, T3, T4, TResult>

could be simplified to:

IFuncWithHandler<T<T1, T2, T3, T4, TResult>>

using this idea.

[HaloFour]

I don't see how Foo<T<U>> would be feasible from a CLR level or practical from a language level. For one, it implies some kind of relationship between T and U that doesn't exist. Why would Foo<Predicate<byte[]>> work but not Foo<Func<byte[], bool>>? The fact that a type might have a generic argument doesn't imply its relationship to that generic argument, or its arity. For it to work in the CLR, the type would still have to be Foo<T, U> because the U has to be a separate generic type parameter so that you can actually use it. Foo<T<U>> implies that there is a single generic type parameter, which would be a distinctly separate type.

I think that issues like this are better solved through better generic inference, where the compiler could infer U based on the shape of T, e.g.:

public void Foo<T, U>(T input) where T : IEnumerable<U> { ... }

List<Person> people = ...;
Foo(people);  // infers T to List<Person> and U to Person

[DavidArno]

@HaloFour,

The Foo<T<U>> construct does express a relationship between T and U. It's is effectively shorthand for Foo<T, U> where T : T<U>, ie it's constraining T to be a generic type with one parameter, U.

And, this issue isn't better solved through better generic inference, as my example sort to show. Such generic inference would save having to casting in some situations, but it doesn't address avoiding duplication parameters.

[HaloFour]

@DavidArno

t's is effectively shorthand for Foo<T, U> where T : T<U>, ie it's constraining T to be a generic type with one parameter, U.

Which, as I'm sure you're aware, isn't a constraint supported by the CLR. Nor is it one that makes sense, because that generic parameter arity doesn't mean anything enforceable. You'd still need additional constraints to actually declare the relationship between T and U, e.g. T : IEnumerable<U>, otherwise it's not like you could actually use T in any meaningful way with U. And in my opinion it still doesn't make sense that having Foo<T<U>> would preclude you from also having an unrelated Foo<A, B>.

[DavidArno]

Which, as I'm sure you're aware, isn't a constraint supported by the CLR...

I'll take your word for it. I know that C#'s generic constraints are frustratingly limited, but I've never looked into whether that's a language, or runtime, limitation.

[HaloFour]

@DavidArno

They are runtime limitations. IIRC, the only CLR constraints not supported by C# are enum and delegate.

But even if such a constraint could be added to the CLR/language, what would it mean? Of what practical benefit is a T constrained by T<U> if the compiler/runtime doesn't know what else T could be? It would default to object which has no relationship with any other generic type. So it's not like this constraint would allow you to call any additional methods on T that accept or return U.

[orthoxerox]

@HaloFour the benefit is obvious when you need to have both T<U> and T<V> in your signature. This is something you cannot express without generics on generics.

For example, you can have ISelectable<T> with a single member Select<U>(Func<T,U> func), but you cannot encode the return type of that method to return not just ISelectable<U> but the actual type of the implementer.

With higher-kinded types, you would be able to CRTP around that:

public interface ISelectable<S<T>> where S: ISelectable<S<>>
{
  S<U> Select<U>(Func<T,U> func);
}

public class MyList<T>: ISelectable<MyList<T>>
{
  MyList<U> Select<U>(Func<T, U> func) => ...
}

[HaloFour]

@orthoxerox

Doesn't that become a constraint on S at that point? Of the few times I've seen higher-kinded type syntax suggested for C# that's generally the shape that it's taken. It would make more sense as that does establish a relationship between the generic type arguments. But I'm not sure that I get how ISelectable can then work with T directly if T is not itself a generic type parameter of ISelectable. Other than finding it conceptually interesting I don't think I've seen any real embracing of higher-kinded types by the LDM and that would involve some serious changes to the CLR, no?

[orthoxerox]

@HaloFour what doesn't become a constraint on S, T? Why should it? There's no real relation between them at all, you could probably rewrite the syntax to say ISelectable<S<>, T> where S<> : ISelectable<S<>, T> and MyList<T>: ISelectable<MyList<>, T>. The important feature is being able to pass not a concrete type as the type parameter, but a generic one.

And yes, implementing this at the CLR level would require changes not seen since .Net 2.0.

[HaloFour]

@orthoxerox

No, the fact that S is itself a generic type, like T in this example:

public static T<A> To<T, A>(this IEnumerable<A> xs)
    where T : <>, new(), ICollection<> { ... }

dotnet/roslyn#2212