Expose a way to bridge generic constraints

[tannergooding]

Bridging Generic Constraints

Summary

C# should expose a way to "bridge" generic constraints such that a method void M<T>() { } can successfully call a method void N<T>() where T : struct { } given an appropriate check.

Motivation

Generics were introduced in .NET Framework 2.0 and since then there has been no way to go from a less constrained to a more constrained environment. Additionally, since the initial release there have been several new constraints introduced (such as unmanaged) and several new "core interfaces" (such as INumber<T>) exposed through which users may want to take advantage of functionality. However, given that changing an existing generic constraint (especially to be more restrictive) is most often a binary breaking change, there is no way for these existing generic APIs to utilize this newer functionality and they are effectively "left behind".

Design

C# should expose a syntax that allows a developer to perform a check against a generic type and within the scope of that check they then have ability to call other generic methods that fit the constraint. As an example:

void M<T>()
{
    if (T is unmanaged)
    {
        N<T>(); // This is now valid
    }

    N<T>(); // This remains invalid and errors
}

void N<T>()
    where T : unmanaged
{
}

This would require selecting a syntax, performing the relevant code flow analysis (ideally utilizing some of the flow analysis introduced for nullable annotations to reduce the work required), and ensuring that relevant "well known" APIs exist in the runtime such that the check can be done and the runtime will treat the call as "legal".

For syntax, utilizing the is keyword seems somewhat natural given that is already how certain type checks are done by the language. However, there are other alternative syntaxes that might be possible or better suited instead. For the checks there should at least be a way "bridge" the following constraints:

• where T : class
• where T : struct
• where T : unmanaged
• where T : Type

Bridging other constraints, such as where T : new() may also be desirable but might also be significantly more complex to get support for/around. The ones immediately listed above can at least be "trivially" handled using existing APIs expose by typeof(T).

Open Questions

Should this only work against generic types (given T, you can do if (T is unmanaged)) or should it also work against generic values (given T x, you can do if (x is unmanaged))?

• These do have slightly differing semantics due to inheritance (given T x and T y, if (x is INumber<T>) doesn't imply the same for y).

What is required in the runtime to make these checks performant and valid?

• Will such checks work well with Native AOT?
• Is utilizing the constrained prefix before the call sufficient, similarly to what we do for static abstract calls?

How simple or complex should the flow analysis for these types be?

• My initial presumption is matching what NRT does with regards to null checks would be a good starting point.

How do such checks play with NRTs given that where T : class and where T : class? are both valid?

[tannergooding]

CC. @stephentoub, @jaredpar

This has been raised a few times and does particularly impact the ability to use things like the new Generic Math interfaces from existing types (e.g. we can't use INumber<T> within Vector<T> today).

This is a rough draft starting point on the topic and would be great if we could flesh it out and get championed.

[svick]

Related previous discussion: #905.

[HaloFour]

or should it also work against generic values (given T x, you can do if (x is unmanaged))?

I don't think that would be possible without changing the meaning of existing code, e.g. SharpLab

[tannergooding]

That's if you use is and only for the Type constraint check case, using something like if (obj : IDisposable) would also work and disambiguate (even though the syntax looks pretty bad).

The point of this was to capture a rough draft of the needed issue and suggest a couple potential avenues. Ideally this gets a champion and I can work with that champion to flesh out the design to a "proper proposal", including covering the necessary syntax and spec changes so this can goto LDM.

[Xyncgas]

What if instead of using

void M<T>()
{
    if (T is unmanaged)
    {
        N<T>(); // This is now valid
    }

    N<T>(); // This remains invalid and errors
}

We use template specialization like :

void M<T>() where T : unmanaged
=> N<T>();
void M<T>()
{
    return;
}

or even void M <unmanaged T> ()

[ufcpp]

Your proposal looks like compile-time solution, and the original one is runtime. I want both compile-time and runtime.

[Lancelotbronner]

I would absolutely love the compile-time as it would allow some quite elegant APIs to be made.

[huoyaoyuan]

The combination with static interface method is also very useful:

T GetSmallestChange<T>() where T : INumber<T>
{
    if (T is IFloatingPoint<T>)
    {
        return T.Epsilon; // Interface member resolution? Or just allow delegating to another method to get this?
    }
    return T.One;
}

[tannergooding]

Yes, the intent is the check would allow access to the given members

[koszeggy]

This would be a very important missing link to make static interface members really useful. I proposed something very similar:

public static bool TryParse<T>(this string? s, IFormatProvider? provider, out T? value)
{
    // New code: Shortcut if T is IParseable<T> (now illegal because T is a type, not an instance):
    if (T is IParseable<T> TParseable) // TParseable is a constrained type argument now
        return TParseable.TryParse(s, provider, out value);

    // Original code: trying to use TypeConverters as fallback etc...
}

I went a bit further by using TParseable the same way as normal pattern matching works but it's totally fine to me if this will work the way you proposed.

[HaloFour]

I actually really like that idea, to match the existing generic type parameter into a variable pattern with a new identifier representing the generic type parameter with the constraint, much more than just implicitly considering the existing generic type parameter to be of the matched type in scope.

[MichalPetryka]

This'd result in a very messy code when the type would be checked against multiple interfaces and even more so with multiple generic parameters for the method since then you'd have to constantly check from which one the new pseudo-type was created from.

[Enderlook]

This'd result in a very messy code when the type would be checked against multiple interfaces and even more so with multiple generic parameters for the method since then you'd have to constantly check from which one the new pseudo-type was created from.

The issue may be mitigated if multiple interfaces could be checked at the same time:

void Example<T>()
{
    if (T is (IAlfa & IBeta) T2)
        Example2<T2>();
}

void Example2<T>() where T : IAlfa, IBeta {}

Thought that increases the complexity of the syntax, not sure if that is valid.

[Xyncgas]

I think new c# people are just doing what they want to do until they can't, instead of looking for new things to do in the documentations, so when they try to convince themselves therefore hoping the compiler would infer a type, they provide hints / evidence which usually is a cast operation, the pattern matching works beautifully in this case because when the newbies realizes their cast is going to throw an exception and they need to check for it somehow, they are home

[Enderlook]

What do you mean by using pattern matching in this situation?
Pattern matching is done on the instance (values) while this discussion is about the types themselves. Hence, it can't be used to satisfy generic constraints on called methods.
How would pattern matching solve the described situation above?

[Xyncgas]

I thought

    if (T is unmanaged)
    {

    }

[huoyaoyuan]

T is unmanaged does not enable additional operations on T. Things like sizeof are now possible with unsafe.
If no operations are enabled, typeof(T).IsXXX is sufficient.

[IS4Code]

I've also proposed (#3050) a similar idea which would incorporate it (in my opinion quite nicely) into the existing pattern-matching facilities in the language. This specific issue could be solved:

if(default(T) is new TUnmanaged where TUnmanaged : unmanaged)
{
    // here TUnmanaged exists
}

I can imagine it being possible to write T instead of default(T) some day as well.

[tannergooding]

That only really makes sense for value types. For a reference type T it would be null and that is potentially problematic (both to read and to interpret meaning behind).

This syntax is also very verbose given you really just want to know "is T compatible-with the unmanaged constraint"?

[acaly]

1. Should this be allowed? if (T is IEnumerable<TElement> TEnumerable) This can allow much more optimization and compensate for the inability of partial inference Champion: "Partial Type Inference" #1349.
2. How should the debugger handle "Set next statement"?

[colombod]

Trying to implement math operators over collection of numbers is a problem if the where clause is not helping to direct to specific overloads.

I have a signature

    public static TProbability Expectation<T, TProbability>(this Distribution<T, TProbability> source, int samplesCount)
        where TProbability :  IFloatingPoint<TProbability>
        where T : INumber<T>,IDivisionOperators<T, TProbability, TProbability>

to handle a Distrubiton over a numeric domain T

and a signature

    public static TProbability Expectation<T, TProbability>(this Distribution<T, TProbability> source, int samplesCount)
        where TProbability : IFloatingPoint<TProbability>

that would handle any other case using a probability density function that maps T to TProbability.

This is not possible as the generic constraint is not helping.

Same problem comes up when using matching expression since is not possible to use generic constraints in defining the list of case.

Being able to create ad hoc code for System.Single and System.Double (taking into account the GetExponentByteCount for example) is important in many numeric applications.

Same would expand even more in multidimensional structures like vector and matrix.

[Ethereal77]

I was recently experimenting with the new abstract statics in interfaces and came across this limitation. The imposibility to check if a type T is IParsable<T> outside of using it in a generic constraint detracts from the usefulness of some of these new types.

Also, even if I could test it, I can't access the members of IParsable<T> as it is an interface, and also can't access them on T as it is not the concrete type implementing the interface.

[TonyValenti]

I'm bumping into this limitation as well.

[NoSkillPureAndy]

I would love for this to be possible.

[hez2010]

+1 for this feature. The pattern matching on type parameter can also contribute to redundant branch elision optimization in JIT, which can improve the performance significantly. For example,

T GetSmallestChange<T>() where T : INumber<T>
{
    if (T is IFloatingPoint<T> TF)
    {
        return TF.Epsilon;
    }
    else return T.One;
}

In JIT time the concrete T will be in the generic context so that it will become a known constant and the branch can be completely removed, and if GetSmallestChange gets inlined, it will have no difference than using float.Epsilon/double.Epsilon/int.One/... directly.

[hamarb123]

+1, I've run into this a million times.
Also, as a part of this feature / unsafer unsafeness, the following should also be allowed (and cause a warning):

[acaly]

There is nothing inherently more dangerous about this than reinterpret casting, or using Unsafe.As (which doesn't require an unsafe context), or even half the things you can do via dynamic or reflection.

Its more about allowing users to do something they know is safe while making sure they are aware it is particularly dangerous and error prone.

Totally agree. I have tried tweaking the runtime previously, bypassing generic constraint check, and successfully making codes in this issue to work. When the actual type does violate the constraint, the runtime will throw another exception when the method is called first time and continue to work.

[IS4Code]

Satisfying generic constraints is part of the verification algorithm, and could be done with a runtime check, but the syntax here is the issue. You can't allow something unrelated to pointers (well perhaps related through the aforementioned verification only) just by wrapping it into unsafe. It must be something like X<unchecked T>() or X<T!>() or whatever so that the intent is communicated (no, proclaiming unsafe does not communicate the intent that generic constraints shall be unchecked).

[hamarb123]

As mentioned in earlier replies (by multiple people I believe) it would cause a warning. And type constraints are already checked at runtime (I believe). The intent is communicated by disabling the warning with #pragma or project-wide. And if you do it wrong, unlike with other things such as ignoring scoping or readonly on refs, this would have no chance of crashing the runtime since it is already checked at runtime and will simply throw an error, so it's actually more safe in a way.

[acaly]

You can't allow something unrelated to pointers (well perhaps related through the aforementioned verification only) just by wrapping it into unsafe.

I think C# has changed away from what you said already. It is allowing more unsafe patterns inside the unsafe block. For example, #6476. I remember there is a proposal (which I can't find now) to allow unsafe to really mean unsafe, not limited to pointer safety.

[svick]

@acaly I blieve you're talking about dotnet/runtime#31354.

[sebas77]

I need this as well as explained here: #6838

[Xyncgas]

In F# generics are inferred...

[hez2010]

This won't work in C# as C# is designed to be strongly contracted.

[huoyaoyuan]

F# generic may not work well cross assembly if I'm correct.

[Xyncgas]

F# generics works across assembly, I can use the function in another project and the types gets inferred, as of now

[tannergooding]

@Xyncgas, could you provide a more complete code sample?

F# has several features which aren't represented in standard IL but rather in a custom embedded resource file. Such features only work with F# (there is not even some standard way/library for other environments to access said metadata). These features can often be "erased" at F# compile time, meaning all traces of them existing go away.

Two big examples of such F# features are inline and SRTP. Not all features are this way, but some others like inference exist becauseF# has a very different foundation in how it is typically used and other features it supports. For example, inference works because F# (generally speaking) has a lack of implicit conversions. This means it can avoid ambiguities and many overload resolution problems.

[Sonozuki]

Would this be applicable to whole methods?
In this crude example being able to constrain which methods are available would be very useful:

public class Program
{
    public static void Main()
    {
        new Vector2<float>(3, 4).Normalise(); // method exists
        new Vector2<int>(3, 4).Normalise() // method shouldn't exist
    }
}

public struct Vector2<T>
    where T : INumber<T>, IConvertible
{
    public T X;
    public T Y;

    public float Length => MathF.Sqrt(LengthSquared.ToSingle(null));
    public T LengthSquared => X * X + Y * Y;

    public Vector2(T x, T y)
    {
        X = x;
        Y = y;
    }

    public void Normalise()
        where T : IFloatingPoint<T> // not currently allowed
    {
        if (LengthSquared == T.Zero)
            return;

        var scale = T.CreateChecked(1 / Length);
        X *= scale;
        Y *= scale;
    }
}

[the-avid-engineer]

Though.. I think non-existence would be confusing. It should say "You can't do that, int is not IFloatingPoint<int>" but better

[Sonozuki]

I wouldn't really consider it syntactic sugar, like you mentioned it's a compile time error instead of a runtime error.
I do agree with the error message though, I could see how that could be useful compared to the non discoverable version I mentioned

[the-avid-engineer]

Generic constraints are evaluated at runtime and compile time

[Sonozuki]

Right, but it's the difference between not being able to compile and being able to compile and have to run that code path. Having compile time errors is more efficient to develop with

[the-avid-engineer]

fair enough :)

[the-avid-engineer]

Using the if block seems to indicate you could combine / negate type conditions and even use non-type conditions.

if ((T is not IFoo && T is IFoo2) || x == y)
{

}

Would this overwhelm the compiler/runtime with complexity? If not, ignore the rest of this comment :)

---

If so, maybe allowing the where keyword syntax on a scope block inside methods is more appropriate?

void M<T>()
{
    where T : unmanaged
    {
        N<T>(); // This is now valid
    }

    N<T>(); // This remains invalid and errors
}

void N<T>()
    where T : unmanaged
{
}

Theoretically, you would be able to use the same combinations we already have (multiple constraints on a single generic type, multiple generic types being constrained). The only difference is that the where keyword is available inside the method block on a scoped block, and the code simply doesn't execute if the constraints are not met (as opposed to any kind of error)

[huoyaoyuan]

A further consideration about this feature: if we can allow generic constrained members on T, why couldn't we allow treating variables as concrete types under a similar check?

Consider the following snippet:

if (T is int)
{
    return 42;
}

instead of:

if (typeof(T) == typeof(int))
{
    return (T)(object)42;
}

[NoSkillPureAndy]

That's a great idea.

[Enichan]

Not having this is a particularly big problem in NativeAOT where you can't rely on reflection to force the transition. https://github.com/dotnet/runtime/issues/95953

[jaredpar]

Going to add a few changes to the core sample to help reveal some of the design points I think are interesting:

1. Using the feature to pass around a value to the functions. This seems necessary to make the feature successful as types only seems limiting.
2. Using a type vs. unmanaged because it makes design issues around conversions a bit clearer.

void M<T>(T p) {
    if (T is I1) {
        // Now valid
        N<T>(p);
    }

    // Error
    N<T>(p); 
}

void N<U>(U p)
    where U : I1 {
  p.M();
}

interface I1 { 
  void M();
}

It's important to establish why Establishing why N<T>(p) works. The design seems to imply that within the bounds of if (T is I1) that T is treated as if it were defined as M<T>(...) where T : I1. That though would be contradictory to how is works today with values. Consider as an example:

void G(object o) {
  if (o is string) { 
    // Error! 
    string str = o;
}

The is clause here is simply establishing a truth about the value of o but it has no impact on the type of o. It remains the type object for the entire method. To me it would be very contradictory to have values behave one way with is with types to behave another way. Think it's cleaner if we follow the pattern values have for using a new identifier to represent / store the result of is:

if (o is string s) { 
  // s is a valid identifier here of type string
if (T is T1 where I1) {
  // T1 is a valid type identifier here which has the `I1` constraint 
 N<T1>();
}

Inside the if (T is T1 where I1) block the identifier T1 would be a valid type. Further there would be an identity conversion between T and T1. That means it allows for code like the following:

void M<T>(T p) { 
  if (T is T1 where I1) { 
    T1 local = p; 
    p = local;
 }
}

That system also seemingly works well if you extend this feature set to testing for values. For example:

void M<T>(T p) {
  if (p is T1 where I1) { 
    T1 local = p;
    p.M(); // works   
  }

  if (p is T2 where I1 p2) { 
    p2.M(); // works
  }
}

One part I'm curious about is what are some concrete samples where we're dealing with type only as the original sample does? I can definitely see where this would be valuable when dealing with values but struggling to see the value for types only. Asking because if the feature is limited to values only, the if (p is T1 where I1) case, then it's reducing the concept count significantly.

Issues that are still on my mind:

1. For every non-type constraint supported by the language (unmanaged, new(), etc ...) there will need to be an equivalent runtime helper that supports the stated C# semantics. Otherwise we'd lack the mechanism to implement the is check. Possible we could start by limiting to type constraints only.
2. Is this form of is checking limited to cases where the value / type being tested is a type parameter? Do we want to say allow code like "str" is T where IEnumerable<char> to compile? Intuition is limit to type parameters but want to validate that.
3. For code like if (o is string s) the identifier s is in scope inside and outside the if block. Outside the if block it's simply an identifier that is uninitialized. So it can be used after definitely assigning a value. Not sure if having type parameters defined with T is T1 where I1 should be in scope outside the if cause it seemingly has no value. Or possibly they're in scope but simply unusable.
4. Will need to work with runtime team to establish how this works at an IL level.

[Enichan]

Is this form of is checking limited to cases where the value / type being tested is a type parameter? Do we want to say allow code like "str" is T where IEnumerable<char> to compile? Intuition is limit to type parameters but want to validate that.

As someone who's often needed to bridge generic constraints over the past 10 or so years, I can't recall a single instance where I personally needed to do this outside of a generic function. I also can't personally think of a non-contrived example where you'd want to do this outside of generics. Generally if you're doing this outside of generics, I would assume you'd have a boxed value and a Type instance, but in that case you're already resigned to boxing. I feel like at that point you may as well cast into a new variable using as.

[IS4Code]

@Enichan

Is this form of is checking limited to cases where the value / type being tested is a type parameter? Do we want to say allow code like "str" is T where IEnumerable<char> to compile? Intuition is limit to type parameters but want to validate that.

As someone who's often needed to bridge generic constraints over the past 10 or so years, I can't recall a single instance where I personally needed to do this outside of a generic function. I also can't personally think of a non-contrived example where you'd want to do this outside of generics. Generally if you're doing this outside of generics, I would assume you'd have a boxed value and a Type instance, but in that case you're already resigned to boxing. I feel like at that point you may as well cast into a new variable using as.

Lack of imagination is hardly a justifiable argument against a feature. Personally I can recall about 5 situations in the past year that had me wishing to be able to do that. Generics are cool and whatnot but they are one-sided ‒ if you as a consumer have full control over the type of input and output of a method, they work nicely, but there are definitely situations where you don't know what a method is about to return, but you want to have that type in scope to make operations with it.

I have certainly come across APIs that suffer from this, for example in ImageSharp with the general Image.Load class, you get the abstract Image instance without any knowledge of the pixel format type T necessary to make it a concrete Image<T>, because it is the producer of the method that has control over T, and there is no standard way of exposing the type to the consumer to make it usable without reflection.

However, as much as I would like features like this, I am beginning to believe that this and a handful of similar situations could be solved in a less intrusive or confusing way with #3577 instead, where you could choose the way you would have the types resolved, and it would work with the overpraised AOT compilation too.

[tannergooding]

Lack of imagination is hardly a justifiable argument against a feature

Let's please be nice. Devs are free to give their input/perspective, including that they cannot personally think of a scenario where it would be needed.

If you have counter examples, it is much more productive to give them as a form of "I hit it for this particular scenario" (and then maybe detail one of the scenarios, not just state that you've hit them in the past), that way everyone else can follow along and maybe go "hey, that's a good point, I hadn't thought of that one".

---

If you aren't in a generic context, then I'd tend to agree that you don't "need" a feature like this. You either have an exactly right concrete type, in which case you can just call the method, or you have the ability to do type checks so you can cast to the more derived type and gain access. It might be nice if the feature also worked here and make some conversions simpler, but it's not really a "need" in the same way.

This is very unlike the generic context where you don't know what the T is and where you may not have an instance that you can cast (it might be a static virtual method on a constrained interface you want to access for example or where the T indicates the return type.

[IS4Code]

Let's please be nice. Devs are free to give their input/perspective, including that they cannot personally think of a scenario where it would be needed.

If you have counter examples, it is much more productive to give them as a form of "I hit it for this particular scenario" (and then maybe detail one of the scenarios, not just state that you've hit them in the past), that way everyone else can follow along and maybe go "hey, that's a good point, I hadn't thought of that one".

Sorry, I meant no offence. Sadly too many times I have seen useful features plainly rejected in other contexts just because whoever decided that could not think of a way to use them. That is why I consider it a non-argument; something that shows only the person's thoughts about the feature and not the nature of the feature in general. My mistake to interpret a plain observation of one's recollection as a denying stance.

I will gladly give the concrete situations where I had a use for this:

• https://github.com/IS4Code/SFI/blob/2baab88c9d3995f1badc39c5c5f4988bce922c7d/SFI.Formats/Images/MemoryUtils.cs#L72
• https://github.com/IS4Code/SFI/blob/2baab88c9d3995f1badc39c5c5f4988bce922c7d/SFI.Formats/Images/SharpImage.cs#L102
• https://github.com/IS4Code/SFI/blob/2baab88c9d3995f1badc39c5c5f4988bce922c7d/SFI/DynamicExtensions.cs#L26 (and the places calling that method)
• https://github.com/IS4Code/SFI/blob/2baab88c9d3995f1badc39c5c5f4988bce922c7d/SFI/Tools/Extensions.cs#L302

[Enichan]

To clarify my stance; I was merely responding to the question Jared asked with my personal experience.

[fryderykhuang]

IndexOf and other methods that needs a comparer in MemoryExtensions does not have corresponding lEqualityComparer<> overrides, instead they all forces the equality interface by a generic constraint, now I need the capability discussed here to force the call like this:

    public static int IndexOf<T>(ValueArray<T> src, T value, int startIndex, int count) where T : unmanaged
    {
        if (typeof(T).IsAssignableTo(typeof(IEquatable<T>)))
        {
            src.AsReadOnlySpan(startIndex, count).IndexOf(value); // <-- allow this
        }
        else
        {
            ... // slower path
        }
    }

[hez2010]

This can also be used for HKT purpose:

void Foo<T>(T x)
{
    if (T is IEnumerable<var U where INumber<U>> V)
    {
        var enumerable = x as V;
        var sum = U.Zero;
        foreach (var i in enumerable) sum += i;
    }
}