Allow 'not' generic type constraints

[bgribaudo]

Looking at this repository's list of issues, there are a lot of ideas relating to generics. Here’s another one to add to the mix.

Motivation

If a developer wants to provide method overloads handling specific type parameter cases along with a more general ‘catch all’ overload, it can be tricky to get the complier to resolve to the intended specific type case overload.

For example, the intention below is that the AsSomething() call on the nested array be resolved to the first extension method. However, the C# complier resolves it to the second method.

static class MyExtensions
{
  public static void AsSomething<T>(this IEnumerable<IEnumerable<T>> arg) { }
  public static void AsSomething<T>(this IEnumerable<T> arg) { }
}


// Intention: Resolves to AsSomething<T>(this IEnumerable<IEnumerable<T>> arg)
// Actuality: Resolves to AsSomething<T>(this IEnumerable<T> arg)
new[] { new[] { 1 } }.AsSomething();

// Intention & Actuality: Resolves to AsSomething<T>(this IEnumerable<T> arg)
new[] { new { FirstName = "Joe", LastName = "Smith" } }.AsSomething();

(Based off a real-world situation adapting IEnumerable<T>s to IDataReader. Each item in the enumerable became a data reader record. If T was itself an IEnumerable<>, the items in the inner enumerable become the values of the data reader’s fields. Otherwise, T's publicly readable instance properties become the data reader’s field values. Unfortunately, using a pair of overloads similar to the above didn’t work due to the way the complier handled resolution.)

Idea

Allow more influence over the overload resolution process by indicating that a certain type parameter must not match a given constraint. This could be achieved by allowing the type constraint list to contain not constraints.

static class MyExtensions
{
  public static void AsSomething<T>(this IEnumerable<IEnumerable<T>> arg) { }
  public static void AsSomething<T>(this IEnumerable<T> arg) where T : not IEnumerable<> {} // <-- use of not constraint
}


// Resolves to AsSomething<T>(this IEnumerable<IEnumerable<T>> arg)
new[] { new[] { 1 } }.AsSomething();

// Resolves to AsSomething<T>(this IEnumerable<T> arg) where T : IEnumerable<> {}
new[] { new { FirstName = "Joe", LastName = "Smith" } }.AsSomething(); 

If this were implemented:

• not constraints should allow open (e.g. IEnumerable<>) and partially open (e.g. Dictionary<int,>) types.
• Multiple not constraints should be allowed in a type constraint list (e.g. where T : not IComparable, T : not IConverable).

[Happypig375]

I think ! could be used instead of not. ! is already the boolean "not" operator and introducing a new not keyword will lead to inconsistency.

public static void AsSomething<T>(this IEnumerable<T> arg) where T : not IEnumerable<> { }
will become
public static void AsSomething<T>(this IEnumerable<T> arg) where T : !IEnumerable<> { }

P.S. The curly braces should come after the where clause. Please fix the code.

[LupusInferni315]

I think ! could be used instead of not. ! is already the boolean "not" operator and introducing a new not keyword will lead to inconsistency.

public static void AsSomething<T>(this IEnumerable<T> arg) where T : not IEnumerable<> { } will become public static void AsSomething<T>(this IEnumerable<T> arg) where T : !IEnumerable<> { }

P.S. The curly braces should come after the where clause. Please fix the code.

not is already a pattern keyword, and as such would not add any new keywords into the language, and it would be nice if generic constraints were written more like patterns, such that where T : not IComparable<>, T : not IConvertible<> could be written like this where T is not IComparable<> and not IConvertible<>.

[bgribaudo]

Thanks, @Happypig375. Curly braces typos fixed.

[Joe4evr]

Aside from being utterly confused as to how exclusive constraints are even useful, this is not even remotely the solution to the problem that you describe.

If a developer wants to provide method overloads handling specific type parameter cases along with a more general ‘catch all’ overload, it can be tricky to get the compiler to resolve to the intended specific type case overload.

It's really not tricky, because your problem isn't about the constraints at all; it's all about overload resolution.

// Intention: Resolves to AsSomething<T>(this IEnumerable<IEnumerable<T>> arg)
// Actuality: Resolves to AsSomething<T>(this IEnumerable<T> arg)
new[] { new[] { 1 } }.AsSomething();

What is actually happening is the compiler not inserting an implicit conversion from T[] to IEnumerable<T> for the inner array, because using the array as a T directly is more favorable, so your proposed "not constraint" still wouldn't help you get the right overload. If instead you did

new[] { new[] { 1 }.AsEnumerable() }.AsSomething();

then it would pick your IEnumerable<IEnumerable<T>> overload just fine.

[bgribaudo]

Hi @Joe4evr! Thanks for your comments!

Yes, the desired overload resolution can be achieved if explicit casting is done—but I'm trying to find a way to avoid requiring that casting.

Real-Life Scenario

I authored a library that adapts an IEnumerable<T> to IDataReader (primary use: streaming data to SqlBulkCopy without requiring that the data first be loaded into a DataTable). Each item in the input enumerable becomes a data reader row. If the input enumerable is itself made up of IEnumerable<T>s, then each item in the inner enumerable becomes a field on the data row. Otherwise (that is, if the input enumerable contains something other than IEnumerable<T>s), the publicly-readable properties of T become the data row's fields.

To me, the ideal interface would be a pair of extension methods named AsDataReader, where the library user simply needs to call myEnumerable.AsDataReader() without needing to worry about explicit casting.

Of course, as we've been discussing, this doesn't work as C# stands today. Instead, either in some circumstances the library user is required to manually add a cast or separate method names must be used for the two variations of possible input. (My library went with the latter approach, using AsDataReader for nested enumerables and AsDataReaderOfObjects for the rest.)

How Resolution Would Work

If this proposal were implemented, I'd envision resolution behaving as follows:

To resolve:

new[] { new { FirstName = "Joe", LastName = "Smith" } }.AsSomething();` 

Against:

static class MyExtensions
{
  public static void AsSomething<T>(this IEnumerable<IEnumerable<T>> arg) { }
  public static void AsSomething<T>(this IEnumerable<T> arg) where T : not IEnumerable<> {} // <-- use of not constraint
}

1. First, existing overload resolution rules are be used, ignoring the not constraint. Based on this, the second overload would be chosen as the resolution candidate (i.e. AsSomething<T>(this IEnumerable<T> arg)).
2. Next, the not constraint on that overload is evaluated.
   1. In this case, the complier determines that T is an IEnumerable<> (because it can be implicitly cast to that type), so the complier realizes that it can't resolve to this overload.
   2. It then moves to what previously was the second best resolution candidate (AsSomething<T>(this IEnumerable<IEnumerable<T>> arg)), evaluates it, determines that it is qualified, and uses it.

[HaloFour]

I'm not sure how well this really works as a generic constraint. What you seem to want is explicitly a way to influence overload resolution, and (as you mention) the C# compiler doesn't consider generic constraints as a part of overload resolution. That has been suggested as a part of "bestest betterness".

Otherwise constraints have a very different purpose, namely in limiting the behavior of the generic type argument so that the generic method may use it in a particular manner. The suggested not constraint doesn't fit in this mold at all. Considering that generic type constraints are always a whitelist of functionality it doesn't make much sense to also apply a blacklist. How does that work given overlap? Is it possible to have a constraint of IEnumerator<T>, not IDisposable? What does that even do?

While I understand the frustration in writing the generic methods for your library I think trying to manipulate the CLR (for the constraint) and the language specifically to support that constraint seems a little bit overkill.

I don't know the implementation details of your library or what those two methods accomplish but what I might have done is have the one method interrogate the T generic argument at runtime to determine if it was IEnumerable and treat it differently.

[LupusInferni315]

I'm not quite certain that I would call 'generic constraints' as a pure 'whitelist' since adding constraints at all 'blacklists' everything except those which match the constraints exactly (meaning the more constraints the more types that are NOT compatible) adding a 'not' keyword to constraints (or as some others suggested a '!' operator would not actually diverge from this behavior as it provides additional restrictions or 'exceptions' to the existing constraints, so something like (again as another commenter stated) 'IVector<TSelf, TInternal> where TSelf: !TInternal' only adds the constraint that 'TSelf and TInternal' must be different types

[bgribaudo]

Hello @HaloFour!

I didn't realize that generic type arguments currently are not considered during the overload resolution process. Based on that, my not constraint wouldn't help with the use case I presented—at least, not until something like "bestest betterness" is implemented.

Even if that proposal makes it into the language (which would open the door for my not to help with my use case), you have a good point about not blacklisting diverging from the current generic type constraints are always a whitelist of functionality behavior. Diverging like that might not be the best idea.

[dazinator]

I have an an additional use case for "not constraints".

I'm developing an extension for Microsoft.Extensions.DependencyInjection where I want to provide an API where the consumer can register transient services similar to how they do it already, except I want to disallow them from registering services that implement IDisposable as transient.

For example I want this to cause a compilation error if FooService implements IDisposable:

services.AddTransient<FooService>();

For motivations as to why I would want to create such an Api, there are numerous issues like this one dotnet/aspnetcore#5496 and it is basically because any instance of a transient service that the container creates automatically gets owned by the container and tracked for disposal.. but disposal doesn't happen until the container itself is disposed. Now consider you are resolving many transient instances from a root container or a scope that lives a long time - they accrue and you get memory leak.

Much better imho to prevent transients that implement IDisposable from being registered at all but we need the compiler to enforce that with some kind of feature like this.

[Triggs9]

Another use case: #4038

[windhandel]

The simplest scenario that I have recently run into is 2 classes with same/similar generic constraint (often one inherits from another).

Some Ts implement an interface and should be forced to utilize one of two possible objects, I have no way of enforcing the utilization f the correct class if T implements the interface.

Assuming we have O1<T> and O2<T> and we want to constrain utilization of O2 when T : Interface.

[Heliomance]

I've also run into wanting this - I'm trying to write an extension for IDistributedCache to automatically do the conversion to/from byte[] for me. I tried to do

public static async Task SetAsync<T>(this IDistributedCache cache, string key, T value)
        {
            byte[] encodedValue;

            // blah blah convert value to byte[] and assign it to encodedValue            

            await cache.SetAsync(key, encodedValue);
        }

intending the call at the end to call the version of the method that can only take byte[], but instead it recursively calls itself again.

[bernd5]

Could you provide the full code including IDistributedCache - the non generic exact-matching-overload version should be a better overload.
A simplified version is okay...

[Joe4evr]

So name your extension something different instead, like EncodeAndSetAsync.

[VILLAN3LL3]

I have also a use case for the not/! operator in generic constraints:

I'm using MediatR in my Web Api and wrote a Pipeline Behavior which should be executed for ALL request types but one. Without the not/! operator I have to add a marker interface to all request classes except one.
With the not/! operator I could just exclude the one specific type from the generic definition.

[vgriph]

I would really like a not constraint for generic types in order to allow a class or interface to implement the same interface twice with different generic parameters without running into CS0695

[longwolf]

Actually, a feature like this is already in use in a standard installation. E. g.

Nullable<Nullable<int>> testVar = default;

raises a CS0453

[Xyncgas]

I support advancing the type system

[douglasg14b]

Yes, please, the type system really needs more flexibility as other languages move past the feature-set & ergonomics of C# (The lang, not necessarily .Net). The language design was amazing 10 years ago, but it's becoming more and more constraining as time goes on. We keep getting new sugar & features, but the type system seems stuck in time.

We shouldn't have to rely on runtime type checking when that could be done at compile time, which is a not-insignificant portion of the C# that ends up being written around a business domain.

As for the folks that run on "I don't see how this is useful" look no further than TypeScript.

[Bertramp]

This needs to be implemented, and should be usable in conjunction with the normal type constraint where each addition increases the specificity e.g MyInterface<T> where T : class, not string. It can be resolved at compile time since we have the CTS.

In my experience people rarely use the type constraints because it lacks more flexible specificity. Right now it's pretty much all or nothing - you either pick class/struct or the end of a branch e.g int

[Ai-N3rd]

I have another use case. I was making an IVector<TSelf, TInternal> interface and wanted to do this:

public interface IVector<TSelf, TInternal> :
    // Add 2 vectors together
    IAdditionOperators<TSelf, TSelf, TSelf>, 
    // Add a number to every component, ex. new Vector2(1, 2) + 3
    IAdditionOperators<TSelf, TInternal, TSelf>

This leaves us with:
Error: 'IVector<TSelf, TInternal>' cannot implement both 'IAdditionOperators<TSelf, TSelf, TSelf>' and 'IAdditionOperators<TSelf, TInternal, TSelf>' because they may unify for some type parameter substitutions.

I would like to do:

public interface IVector<TSelf, TInternal> :
    // Add 2 vectors together
    IAdditionOperators<TSelf, TSelf, TSelf>, 
    // Add a number to every component, ex. new Vector2(1, 2) + 3
    IAdditionOperators<TSelf, TInternal, TSelf>
    where TInternal : !TSelf

Which results in no error.