Fail to compile C# 14.0 extension with interface constraint using implicit additional type parameters

[xoofx]

Hey, ☺️

I'm playing with the C# 14.0 extension feature and love it! While experimenting I discovered the following issue:

    public struct AStruct<K, V> : AStruct<K, V>.AnInterface<AStruct<K, V>>
    {
        public interface AnInterface<out T>
        {
        }
    }

    // Compiles fine
    public static void Ok<T, K, V>(T @this) where T : AStruct<K, V>.AnInterface<T>
    {
    }

    // CS9295 on @this
    extension<T, K, V>(T @this) where T: AStruct<K, V>.AnInterface<T>
    {
    }

And the @this parameter is getting flagged with:

Program.cs(67,26,67,31): error CS9295: The extended type 'T' must reference all the type parameters declared by the extension, but type parameter 'K' is not referenced.
Program.cs(67,26,67,31): error CS9295: The extended type 'T' must reference all the type parameters declared by the extension, but type parameter 'V' is not referenced.

I would believe that it is a scenario that should be supported. Thoughts?

[xoofx]

Just to clarify with this use case, this is not a theoretical case but something I have to currently workaround. I'm trying to build a new modern/low-level wrapper of Objective-C Apple APIs and it happens that, from a client perspective, interface/protocols in Objective-C maps much better with the "extension everything" model.

For example:

public struct NSDictionary<K, V> : NSDictionary<K, V>.ObjCInterface<NSDictionary<K, V>>
{
    public interface ObjCInterface<out T>;
}

public struct NSMultiDictionary<K, V> : NSMultiDictionary<K, V>.ObjCInterface<NSMultiDictionary<K, V>>
{
    public interface ObjCInterface<out T> : NSDictionary<K, V>.ObjCInterface;
}

extension<T, K, V>(T @this) where T: NSDictionary<K, V>.ObjCInterface<T>
{
    public static T @new() => throw new NotImplementedException(); // Actual obj_msgSend call
    public V objectForKey(K k) => throw new NotImplementedException(); // Actual obj_msgSend call
}

// Usage
var dict = NSDictionary<NSString, NSString>.@new();

In the example above, the extension method can apply to both NSDictionary and NSMultiDictionary and you can see that both generic parameter K & V are used as well as the T - which is the equivalent of instancetype type in Objective-C.

[KathleenDollard]

Couple of quick questions on this.

• How do you expect the type parameter V to be determined?
• For the static, how do you expect T, K and V to be determined?
• Can you write this as:

extension<T, K, V>(NSDictionary<K, V>.ObjCInterface<T> @this)
{
    public static T @new() => throw new NotImplementedException(); // Actual obj_msgSend call
    public V objectForKey(K k) => throw new NotImplementedException(); // Actual obj_msgSend call
}

I'm actually not certain that would work as I do not know if we consider nested types. Let me know if you try that.

[tannergooding]

@KathleenDollard a similar need also exists for System.Numerics.Tensors

That is, the libraries team will have the need for:

extension<TTensor, TScalar>(TTensor)
    where TTensor : IReadOnlyTensor<TTensor, TScalar>
    where TScalar : IAdditionOperators<TScalar, TScalar, TScalar>
{
    public static TTensor operator +(TTensor left, TTensor right);
    public static TTensor operator +(TTensor left, TScalar right);
}

I think, however, that the resolving is a little bit easier to determine because the TTensor constraint exists in such a way that both generic type parameters should be resolvable.

That is, TTensor itself must implement IReadOnlyTensor<TSelf, T> where TTensor is itself the first type parameter and TScalar is the second, so TScalar is resolvable provided that it implements IAdditionOperators<TScalar, TScalar, TScalar>

In typical cases, you will have something like class Tensor<T> : IReadOnlyTensor<Tensor<T>, T> or maybe class TensorInt32 : IReadOnlyTensor<TensorInt32, int> and so there is only one possible constraint to resolve.

You theoretically could have something like class CustomTensor : IReadOnlyTensor<CustomTensor, int>, IReadOnlyTensor<CustomTensor, byte>, and so it wouldn't know what to call for CustomTensor + CustomTensor, but that is a reasonable ambiguity and unlikely to occur for such an interface in the real world. So I'd be fine with the compiler erroring

[tannergooding]

In xoofx's case, I'd speculate that the typical case is that a given type only implements one ObjCInterface<T> and so given T.@new() or value.objectForKey(key) it should be able to resolve all of T, K, & V by looking at what interfaces T implements (or the type of value implements). Given that it must implement NSDictionary<K, V>.ObjCInterface<T> given the constraint that exists

Its mostly only ambiguous if a type implements multiple of the interface with different generic types. But some of those will themselves be restricted based on recursive constraints.

For example, interface IReadOnlyTensor<TSelf, T> where TSelf : IReadOnlyTensor<TSelf, T> and I imagine that interface ObjCInterface<T> is similarly where T : NSDictionary<K, V>.ObjCInterface<NSDictionary<K, V>> given how it's used, which limits the ability to implement multiple of the same interface in many cases

[xoofx]

• How do you expect the type parameter V to be determined?
• For the static, how do you expect T, K and V to be determined?

It should be similar to how this is resolved today for a syntax that compiles fine:

// Compiles fine
public static void Ok<T, K, V>(T @this) where T : AStruct<K, V>.AnInterface<T>
{
}

T is always a concrete type (struct) fully resolve-able.

Can you write this as:

extension<T, K, V>(NSDictionary<K, V>.ObjCInterface<T> @this)
{
    public static T @new() => throw new NotImplementedException(); // Actual obj_msgSend call
    public V objectForKey(K k) => throw new NotImplementedException(); // Actual obj_msgSend call
}

Not really, as NSDictionary<K, V>.ObjCInterface<T> would box the struct, also T being itself NSDictionary<K, V>.

For now, I have to specialize with something that requires duplication in case when T has generics:

extension<K, V>(NSDictionary<K, V> @this)
{
    public static NSDictionary<K, V> @new() => throw new NotImplementedException(); // Actual obj_msgSend call
    public V objectForKey(K k) => throw new NotImplementedException(); // Actual obj_msgSend call
}
extension<K, V>(NSMultipleDictionary<K, V> @this)
{
    public static NSMultipleDictionary<K, V> @new() => throw new NotImplementedException(); // Actual obj_msgSend call
    public V objectForKey(K k) => throw new NotImplementedException(); // Actual obj_msgSend call
}

But it's really not great. It duplicates the entire inheritance of methods for all types that implement generics in Objective-C.

In xoofx's case, I'd speculate that the typical case is that a given type only implements one ObjCInterface<T>

Yes, that's the case. Objective-C interfaces are actually classes, like C#, so they only allow single inheritance. I'm using interface because I'm using structs (instead of classes like Xamarin.MacOS) for all these Objective-C instances, and interface allow them to be used with generic constraints which maps well with C# model.

[xoofx]

As @AliveDevil mentioned on Masto, the following code, while "compiles fine", is not really usable without specifying all generic arguments... It seems I keep forgetting about this detail 😅

// Compiles fine
public static void Ok<T, K, V>(T @this) where T : AStruct<K, V>.AnInterface<T>
{
}

Anyway, maybe that's an opportunity to make it working for good?

Also to be clear, extension members are still plenty useful without this support. ☺️

[AliveDevil]

Copied from my reply on Mastodon:

Your sample Ok()-method compiles, but doesn't work the way you want it to as you have to specify all generic types when calling Ok():

AStruct<int, int> v;
v.Ok(); // Bad, CS0411
v.Ok<AStruct<int, int>, int, int>(); // Ok

---

Anyway, maybe that's an opportunity to make it working for good?

Adding nested-type generic inference would be much appreciated, though.

[jcouv]

The inferrability check is currently by design, but from discussion with WG, we're planning to relax it.