Unable to provide method level constraints for class level generic parameters.

[SarcoZ]

some generic interface like this:

public interface IPack
{
///

/// Key
///

TKey Key { get; }
}

public interface IPack<TKey, THeader, TBody> : IPack<TKey>
{
    /// <summary>
    /// Header
    /// </summary>
    THeader Header { get; }

    /// <summary>
    /// Body
    /// </summary>
    TBody Body { get; }
}

/// <summary>
/// Pack A
/// </summary>
public class PackA : IPack<string, string, byte[]>
{
    /// <summary>
    /// 
    /// </summary>
    public string Key { get; private set; }

    public byte[] Body { get; private set; }

    public string Header { get; private set; }
}

/// <summary>
/// Pack builder
/// </summary>
/// <typeparam name="TPack"></typeparam>
public interface IBuilder<TPack> where TPack : IPack<string>
{
    byte[] BuildPack(TPack pack);

    /// <summary>
    /// this is not my need,only sample,it can be compile success
    /// </summary>
    /// <typeparam name="TSubPack"></typeparam>
    /// <param name="pack"></param>
    /// <returns></returns>
    byte[] BuildPack<TSubPack>(TPack pack) where TSubPack : TPack;

    /// <summary>
    /// why this not support? 
    /// I think this is very useful,any other I must be define IBuilder<TPack,THeader,TBody> where TPack:IPack<string, THeader, TBody>
    /// which is non convenient when use
    /// </summary>
    /// <typeparam name="THeader"></typeparam>
    /// <typeparam name="TBody"></typeparam>
    /// <param name="pack"></param>
    /// <returns></returns>
    byte[] BuildPack<THeader, TBody>(THeader header, TBody body)
        where TPack : IPack<string, THeader, TBody>;
}

Is this can be support?

[SarcoZ]

scala use :< and :> to constraints type,can c# support this feature?

[HaloFour]

In the CLR the generic type constraints are a part of the generic type parameter and they cannot be defined separately, nor can the constraints be narrowed/modified by a different scope (e.g. method or nested type).

In Scala the generics are erased during compile time so the language can be a little looser with the rules. In C# the generic arguments are not erased. To change how the generic type constraints work in C# would require modifications to the runtime to support those kinds of constraints.

[bondsbw]

Suppose that TPack does not implement IPack<string, THeader, TBody>. What is the expectation here? Compile error at the call site?

byte[] BuildPack<THeader, TBody>(THeader header, TBody body)
        where TPack : IPack<string, THeader, TBody>;

[VisualMelon]

@HaloFour I'd have thought you could fudge this without CLR changes the same way as a programmer would, by defining a new type param, TPack*, which must be satisfied at the call site (which is necessarily the same type as TPack, so the C# compiler just throws that at it), and is otherwise transparent.

Something like

// within class `Class<T>`
public static int Compare<S>(T l, S r) where T : IComparable<S>
{
    return l.CompareTo(r);
}
Class<T>.Compare<CS>(t, s); // t of type T, s of type S

to

public static int Compare<S, TStar>(TStar l, S r) where TStar : T, IComparable<S>
{
    return l.CompareTo(r);
}
Class<T>.Compare<CS, T>(t, s);

I'm not sure if TStar : T (or if it should just inherit the same constraints as on T) makes sense, but I don't immediately see why this can't be done without CLR changes, though it does at first seem untidy, but it might make some sense.

I could also easily be missing something.

(I'm guessing the long comment on the OP's example is something like this... I just can't stroll or copy the text because my browser and github do not get along)

---

Eh, I've changed my mind/this is wrong. This wouldn't be so easy, because existing references to T held by the class would not be known to be TStar, and sadness would ensure.

[bondsbw]

This proposal boils down to allowing

class C<T>
{
    void M() where T : {constraint}
    {
    }
}

which desugars into

class C<T>
{
    void M<T*>() where T* : T, {constraint}
    {
    }
}

But without any further changes, the call site would still require the type parameter:

MyClass mc = ...
mc.M<MyClass>();

I doubt that #1349 would automatically be able to infer the type parameter. But if it could, then we could reduce to

mc.M();

or at least

mc.M<>();

[VisualMelon]

@bondsbw if the compiler is covering over T* in the method definition, then it can probably hide away T* at the call-site also by just throwing meta-data at the method. However, what frightened me, is that inside the method, it would also need to cast instances of T handled by the method to T*, and then I think the sugar comes off, because only languages which recognise the C# specific no-clr-change-please-meta-data will guarantee they are calling it with T* = T.

[bondsbw]

@VisualMelon Right, any usage of the constrained type in the method would require a cast from T to T*, even if they are equal. The compiler can't guarantee that.

So to fix that issue we would need an "equals" type constraint, e.g. where T* = T instead of where T* : T. But now we're back to changing the CLR, so we might as well give this proposal first-class support.

[VisualMelon]

@bondsbw yup, that's pretty much the measure of my assessment.

[SarcoZ]

@bondsbw Yes, compile error at the call site if the TPack does not implement IPack<string, THeader, TBody>,this is what my expect.

[SarcoZ]

Next version can improve this issue?

[jnm2]

I use extension methods to address this in some limited scenarios.

[SarcoZ]

@jnm2 Up to today，When will this issue be solved?

[jnm2]

@SarcoZ As of today, I'm not aware of a plan to solve this issue.

[SarcoZ]

@bondsbw next version can give this proposal first-class support? this can reduce the number of generic parameters

[bondsbw]

@SarcoZ This proposal has not been championed, and changing the CLR has an extremely high bar even compared to language changes. So probably never, to be realistic.

Not to say it is a bad proposal. Just that it needs a change which could break forward compatibility in the CLR and it requires a huge commitment from multiple design and implementation teams.

[rummelsworth]

Can the title of this issue be updated to clearly reflect that its about lower bound type constraints? (Per the closure reason at dotnet/coreclr#20505?)

I'd find this feature useful, and it'd be nice for the title here to be more direct about what this issue actually is, so that interested folks can find it more easily and show their support.