Proposal: Value generic parameters

[DjArt]

I suggest add to C# and CLR support of value generic parameters. Small example:

//T is usual generic parameter
//S is value generic parameter
class Vector<T, uint S>
{
	//Example of fixed-length array with value generic parameter
	private T[S] _Store;

	public Vector()
	{
		_Store = new T[S];
	}
	
	//Example of usage 'params' with fixed-length arrays
	public Vector(params T[S] elements)
	{
		_Store = elements;
	}
	
	//Creating new object with value generic parameter
	//that was calculated in compile-time
	public Vector<T, uint SNew> Concat<SNew, SY>(Vector<T, uint SY> y)
		//There are expression that can be calculated in compile-time
		where SNew = S + SY
	{
		T[SNew] elements = new T[SNew];
		Array.Copy(_Store, elements, S);
		Array.Copy(y.Store, 0, elements, S, SY);
		return new Vector<T, uint SNew>(elements);
	}
}

And example of usage:

class Program
{
	const uint T = 8;
	
	static void Main(string[] args)
	{
		//that ok
		Vector<float, 4> r = new Vector<float, 4>();
		//that too
		Vector<float, T> r1 = r.Concat(r);
		uint n = 12;
		//That are wrong - we need compile-time value
		Vector<float, n> w = new Vector<float, n>();
	}
}

Of course, all generic parameters must be resolved in compile time, so all values, that can be passed as value generic parameter must be declared as constants. This limits the possible types that can be used as value generic parameters.

[Joe4evr]

This has been proposed before but I can't find it on mobile.

[TonyValenti]

I'm actually curious why this value should be passed in as a generic parameter - I really think this would be better done as a constructor parameter.

[Unknown6656]

I do like the proposal in general, however, one would have to generate (as is the case with C++) one type per used uint constant, meaning that if 3 and 2 are used as vector dimensions, the compiler would have to generate $vector2<float> and $vector3<float>.
My point is, that the value generic parameter would be erased during compilation (due to the runtime not supporting such a thing). This would also mean that this feature would be inaccessible to reflection.

@TonyValenti : the idea would be to provide type safety at compile-time. This would e.g. prevent someone from multiplying a matrix<float, 3, 4> with a matrix<float, 2, 2> etc.

[HaloFour]

IMO all of the compelling use cases for such a feature (e.g. fixed length arrays) also require that the compiler or runtime spin out a different runtime type for each permutation of the generic argument. But I think this would also make them very limited and difficult to work with. Even the proposal demonstrates some kind of generic constraint to allow the compiler to perform expressions on the generic type arguments to derive the value of generic type arguments at compile-time, which brings generics into the world of templates in some weird hybrid way.

[HaloFour]

There have been a couple of other similar proposals opened, they all seem closed now:

#2393
#1185

[Richiban]

FWIW, doesn't Rust have this, specifically for arrays? It's the only instance of dependent types in ithe language but [i32; 5] and [i32; 6] are dufferent types to the compiler.

While I love this idea, you'd need to go a lot further than just allowing a value as a type parameter to make it useful; you'd need to build some arithmetic into the compiler. Otherwise, for example, arrays would need to be exactly the right size to be assignable, rather than just at least the right size.

[IS4Code]

Fixed-size buffers would definitely improve with this, but implementing this properly is a very tedious task.

Even for this simple type:

class Constant<int V>
{
    public const int Value = V;
}

If the type shall be truly generic (and not just a template), this would mean that every integer has to be encoded as a type, in order not to break every code that does reflection with generics. This means there has to be both an agreed-upon method to encode bytes into an unique type, but also a way to query a value of such a type in CIL. For a const field, the encoding would be modified.

Even for a fixed-size buffer, its size is controlled via the .size directive in CIL, which takes an int32. Unless the encoding is modified, there is nothing at runtime to give you a type of a specifiable size, unless you compose it recursively with generic types.

Without modifying the encoding, the runtime could be modified to allow a special type FixedSizeArray<T, V> which would have its size dynamically obtained from V. V can be represented with bits like EncodedValue<_0, _0, _1> which would resolve to 4 (least-significant bit first). With some deal of helper methods to obtain the encoded value, it could be implemented.

There are also other places where this seems to be logical but would be quite hard to get into, like arguments of attributes or default values of parameters.