[Proposal] Simplify generic type parameters declaration

[hypeartist]

The proposal is to make it possible to declare generic type parameters more straightforward.

This is existing implementation:

Declaring some types and interfaces:

public interface IInterface1A<T>
    where T : unmanaged
{
	void Method1A(T t);
}

public interface IInterface1B<T, U>
    where T : unmanaged
	where U : IInterface1A<T>
{
	void Method1B1(T t, U u);

	void Method1B2(U tu);
}

public class Class1<T, U, V>
    where T : unmanaged
    where U : IInterface1A<T>
	where V : IInterface1B<T, U>
{
	void Method1(T t, U u, V v)
	{		
	}

	void Method2(T t, U uv)
	{
	}

	void Method3(V tuv)
	{		
	}
}

public struct Struct1A<T> : IInterface1A<T>
    where T : unmanaged
{
	public void Method1A(T t) {}
}

public struct Struct1B<T, U> : IInterface1B<T, U>
	where T : unmanaged
    where U : IInterface1A<T>
{
	public void Method1B1(T t, U u) {}

	public void Method1B2(U tu) {}
}

public interface IInterface2A<T>
    where T : unmanaged
{
	void Method2A(T t);
}

And use them:

var c1 = new Class1<byte, Struct1A<byte>, Struct1B<byte, Struct1A<byte>>>();

And this how it would be according to the proposal:

Declaring some types and interfaces:

public interface IInterface2A<T>
	where T : unmanaged
{
	void Method2A(T t);
}

public interface IInterface2B<T<U>>
	where T : IInterface2A<U>
	where U : unmanaged
{
	void Method2B1(T t, U u);

	void Method2B2(T<U> tu);
}

public class Class2<T<U<V>>>
	where T : IInterface2B<U<V>>
	where U : IInterface2A<V>
	where V : unmanaged
{
	void Method1(T t, U u, V v) { }

void Method2(T t, U<V> uv) { }

void Method3(T<U<V>> tuv) { }
}

public struct Struct1<T> : IInterface2A<T>
	where T : unmanaged
{
	public void Method2A(T t) { }
}

public struct Struct2<T<U>> : IInterface2B<T>
	where T : IInterface2A<T>
	where U : unmanaged
{
	public void Method2B1(T t, U u) { }

	public void Method2B2(T<U> tu) { }
}

And use them:

var c2 = new Class2<Struct2A<Struct2B<byte>>>();

[HaloFour]

IMO this doesn't make the declaration of the generic types any simpler.

At consumption this becomes ambiguous as classes are different based on their generic arity and your second example would be indistinguishable from Class2<T>.

[hypeartist]

@HaloFour

and your second example would be indistinguishable from Class2

You may consider this as syntatic-sugar compiler magic which just expands

Class2<Struct2A<Struct2B<byte>>>

into its "real" form:

Class1<byte, Struct1A<byte>, Struct1B<byte, Struct1A<byte>>>

IMO this doesn't make the declaration of the generic types any simpler.

The declaration would become more straghtforward, less repetitive, always twice as shorter in typing, and much better for visual perception and easier for understanding

[HaloFour]

@hypeartist

You may consider this as syntatic-sugar compiler magic which just expands

That's my point. This looks like Class2 has a single generic type argument when it really has three. There can be both Class2<T> and Class2<T, U, V> in scope and the compiler wouldn't know how to tell the difference between them. Having the explicit generic arity eliminates a lot of potential ambiguity.

I'd rather have better generic type inference which would make it possible to omit the generic type arguments entirely.

The declaration would become more straghtforward, less repetitive, always twice as shorter in typing, and much better for visual perception and easier for understanding

I don't see much of an appreciable difference between the two:

public class Class2<T<U<V>>>
	where T : IInterface2B<U<V>>
	where U : IInterface2A<V>
	where V : unmanaged { }

public class Class1<T, U, V>
	where T : unmanaged
	where U : IInterface1A<T>
	where V : IInterface1B<T, U> { }

[hypeartist]

@HaloFour

I don't see much of an appreciable difference between the two

In case of declaration - sure yes (seems like I was a little misleading with the issue title - my bad)!
By the when it comes to actual using (instanition or calling) here comes those overtyping hell, where we should steadily repeat same types untill we get to U:

Class1<byte, Struct1A<byte>, Struct1B<byte, Struct1A<byte>>>

[hypeartist]

@HaloFour

Oh! I am stupid! I just realized what you meant with:

There can be both Class2 and Class2<T, U, V>

What about just raise roslyn (code analyzer) ambiguity error in this case and let a dev to fix it choosing what he actually need?

[HaloFour]

@hypeartist

What about just raise roslyn error in this case?

Why would that be a compiler error? It's perfectly legal to have Class2, Class2<T>, Class2<T, U>, Class2<T, U, V>, etc. System.Tuple<...>, System.Action<...> and System.Func<...> are good examples of these.

You also might want to take a look at #339 as I think there may be some conceptual overlap.

[hypeartist]

@HaloFour

Why would that be a compiler error?

I mean trigger error in case we have declarations which may cause potential ambiguity:

class Class<T<U<V>> {} // T has no constraints
class Class<T> {} // T has no constraints, so T can be anything including T<U<V>>

or

class Class<T<U<V>> where T : IInterface {} 
class Class<T> where T : IInterface {} // same as above - T can be T<U<V>> too

so when we will try to instaniate them:

new Class<OtherClass>()
new Class<OtherClass<Struct<byte>>>()

compiler whould raise error about ambigious usage (since it's unable to determine which class to use).

PS: as of #339 - it seems like a different story to me

[LokiMidgard]

I think this is kind of what I was searching for, just a little bit different.

What I would like to archive is the same (I think) but I would do it the other way around.

public class MyList : List<int> { }

// Today:
public static void Foo<TList, TItem>(TList list)
    where TList : List<TItem> 
    where TItem : struct {}

public static void Bar<TList, TItem>()
    where TList : List<TItem> => typeof(TItem);

Foo<MyList, int>(new MyList());
Bar<MyList, int>();


// Future (I wish)

public static void Foo<TList, {TItem}>(TList list)
    where TList : List<TItem> 
    where TItem : struct {}

public static Type Bar<TList, {TItem}>()
    where TList : List<TItem> => typeof(TItem);

Foo(new MyList());
Bar<MyList>(); // returns the int type

The curly braces around the generic type argument acutally mean those are not existent. So Bar<TList> has only one type argument. The second Type Argument TItem is only Method internally visible and must be inferencable from other type arguments. It is not part of the method signature.

I'm not sure if this would provide the same benefit @hypeartist wanted. But if it would, it should not have the problem with the ambiguity. On the other hand it is probably more then syntactic sugar.