[Proposal] Const blittable parameter as a generic type parameter - constexpr used for blittable type parametrization

[4creators]

Const blittable generic parameter syntax

• Proposed
• Prototype
• Implementation
• Specification

Rationale

C# generics do not allow for non-type generic parameters, such as class C<int i>{}.
Ability to parametrize generic type with non-type parameters provides additional expressiveness in language which allows to support large class of new and useful code patterns. Constraining non-type generic parameters to constexpr blittable values (see issue #206) simplifies significantly implementation and provides most desired feature - predefined, controllable memory layout.

public unsafe struct Tensor<T, const int N> where T : struct
{
    public fixed T [N];    // compile time error 
}

Combining above syntax with proposal from issue #653 allows for even more expressive syntax

public unsafe struct Tensor<T, const int N> where T : byte, sbyte, short, ushort, int, uint, long, ulong, float, double 
{
    public fixed T [N];    // OK 
}

Currently attempt to implement struct Tensor<T, const int N> for T : (byte, sbyte, short, ushort, int, uint, long, ulong, float, double) and for dimensions N: (1 ... 128) would result in creation of 1280 Tensor related structure types.

Situation gets even worse if we try to work with matrices composed of struct Tensor<T, const int N>

public unsafe struct Matrix<T, const int X> where T :  struct Tensor<T, const int Y>
{
    public fixed T [X]; 
}

If we want to work with matrices with dimensions Y: (1 ... 128) and X: (1 ... 128) we would need to create 163 840 Matrix related types for all underlying numeric types.

What we want to do next is of course creation of some implementations of useful algorithms which would operate on Tensor and Matrix derived structures. Let's assume we want to have all basic operations ....

All above examples could be simplified to implementation which does not require fixed arrays but still relies on constant dimensions. This problem was already encountered in the framework and runtime implementation where .NET Framework developers decided to provide optimized implementation for 2 out of 163 840 Matrix types System.Numerics.Matrix3 and System.Numerics.Matrix4 which are hand crafted specializations of Matrix<Tensor<float, 3>, 3> and Matrix<Tensor<float, 4>, 4>. How about Matrix<Tensor<double, 3>, 3> and Matrix<Tensor<double, 4>, 4>?

Alternatives

In System.Drawing assembly there are matrices used for large set of transformations based on System.Drawing.Imaging.ColorMatrix. Constructor for ColorMatrix and initialization code example from MSDN is as follows:

public ColorMatrix(
	float[][] newColorMatrix
)


    ImageAttributes imageAttributes = new ImageAttributes();
    float degrees = 60f;
    double r = degrees * System.Math.PI / 180; // degrees to radians

    float[][] colorMatrixElements = { 
        new float[] {(float)System.Math.Cos(r),  (float)System.Math.Sin(r),  0,  0, 0},
        new float[] {(float)-System.Math.Sin(r),  (float)-System.Math.Cos(r),  0,  0, 0},
        new float[] {0,  0,  2,  0, 0},
        new float[] {0,  0,  0,  1, 0},
        new float[] {0, 0, 0, 0, 1}};

    ColorMatrix colorMatrix = new ColorMatrix(colorMatrixElements);

    imageAttributes.SetColorMatrix(
       colorMatrix,
       ColorMatrixFlag.Default,
       ColorAdjustType.Bitmap);

The consequence of the above implementation is that there are no compile time checks for the correctness of ColorMatrix initialization. One can pass float[7][5] array as well. Errors will be detected only at run time. This situation leads to possibility of introducing the whole class of simple or subtle bugs into implementations based on ColorMatrix pattern which can be detected only at run time with additional run time checks which have to be implemented and executed. This lowers both developer productivity and run time performance.

Positives

Proposed feature eliminates whole class of bugs and run time errors increasing at the same time developer productivity by enhancing language expressiveness.

Negatives

May require significant work to be implemented.

[4creators]

Related but different proposal with different use cases #78 #685 'fixed-size-buffers'

[orthoxerox]

See also #357

[4creators]

@orthoxerox I think there is whole bag full of generics or in general type system enhancement proposals like #339 Higher Kinded Polymorphism cited in #357 and it looks like type system supported by CLI and C#/F# needs urgently major upgrade.

[Pzixel]

@4creators generics are not templates. They are working over Type calculus and it's an awful idea to emulate it via generics. What's wrong with:

public unsafe struct Tensor<T> where T : struct
{
    public fixed T[] Foo;
    
    public Tensor(int n) => Foo = new T[n];
}

except that currently it's not possible to do in C#? This proposition makes much more sense to me.

[HaloFour]

@Pzixel

blittable should solve half of that equation. However, I think that fixed and dynamically-sized arrays would remain incompatible conceptually because the CLR has to determine and allocate the memory for the instance before the constructor is invoked.

[4creators]

@Pzixel Absolutely agree that generics are not templates but IMO generics provide for managed languages significantly better abstraction for programming with type parametrization than C++ with templates. I know MSDN entry you linked to and I have consulted it before writing proposal but I do not agree that my proposal violates C# generics principles. It is not supported now but for users it should be very intuitive.

What is overlooked in my proposal is the usage of const keyword which results in several consequences: (i) constexpr generic parameter has to be defined at compile time, (ii) fixed size buffers do not have Length property and in this case since size of the buffer is defined at compile time it will be available at runtime from runtime type system for jit, gc and even reflection and will allow to perform all required allocations and GC collections, (iii)

What's wrong with (@Pzixel example):

The main difference is that size of public fixed T[] Foo; is unknown at compile time. The consequences are quite big from safety, structure layout and possible usage patterns which depend on layout and from code error checking or code correctness perspective.

Firstly, fixed array does not contain size information and since runtime would have no knowledge about array size it would prevent effective bounds checks (if needed) unless it would be an ordinary managed array containing information on it's size. Arrays in type system have a layout containing field with a pointer to buffer and an integer field containing buffer size. This syntax change would destroy one of the most important parts of the proposal from my perspective - predefined size and layout of structure in memory. This would prevent using it to represent i.e. pixels of an image in packed pixel format - there are dozens of pixel formats used in imaging.

Secondly, by using constructor parameter intializing size of the fixed array during type initialization at runtime we loose all advantages brought by statically typed language - compile time control of syntactic type correctness and as a result we end up with dynamic array.

Thirdly, it is impossible to construct blittable types while proposed generic pattern allows it. To some extent it

As a counter example let's have a look at following code snippet - I want to multiply 11 x 7 Matrix by 7 element Tensor what would give as a result 7 element Tensor (Matrix is as above but with corresponding to Your example modifications):

public unsafe struct Tensor<T> where T : struct
{
    public fixed T[] Foo;    
    public Tensor(int n) => Foo = new T[n];
    public Tensor<T>[] Multiply(Matrix<T, Tensor<T>> matrix, Tensor<T> tensor);
}

public static class Matrix
{
    public static Tensor<T> Multiply<T>(Matrix<T, Tensor<T>>, Tensor<T>) { ... }
}

Matrix<double, Tensor<double>> m = new Matrix<double, Tensor<double>>( 5, new Tensor<double>[][]{ new Tensor<double>[]{ ........... }, ..... new Tensor<double>[] { ................ } });

Tensor<double> t = new Tensor<double>(3); // we pass t through several calls until

for (int i = 0; i < t.Length; i++)    // We do not have Length property on Foo unless it's standard managed array what is incompatible with proposal
    t.Foo[i] = Math.Sin((double)i);

var result = Matrix.Multiply<double>(m, t);  // error at runtime - AccessViolationException and corrupted memory

@HaloFour my proposal explicitly eliminates possibility of having dynamic arrays as non type parameter constraint is that it has to be constexpr proceeded with 'const' keyword used in it's current syntactic meaning but in different context - compile time generic parameter. Most probably my description was not clear - will edit it to expose main points of proposal better.

AFAIR there is nothing in current generics implementation that prevents extending it with const blittable (my preference) or const value parameter. There would be changes to clr (vm, type system, jit, gc and debug support) and BCL, in particular System.Reflection namespace and Type, Activator and other classes. In my opinion it's worth the effort - more concrete examples later.

[ufcpp]

I want this feature for this library: https://github.com/ufcpp/BitFields/

[Pzixel]

@4creators I see usecases for this feature however I think if we add such a possibility we can free the jinn. I guess we'd better have some another mechanism beside generics. I don't mind as user if array has length 4 or 5, but it would be completely different type and I have to specify that method receives Tensor<3>. We gen completely different design if we change a common array with a fixed one, and it's not only related to implementation. but to its interface too.

I'm also not sure it will work fine with current __Cannon design for reference type generics. As you understand, your proposal has a primary objective to allow generics over fixed arrays, but they have to be valid in any generic context.

[4creators]

Above referenced API Proposal would directly benefit from generics enhancements described here see https://github.com/dotnet/corefx/issues/22940

[ymassad]

Would this feature allow strings as generic parameters?

E.g.

public class Class1<const string name>
{

}

var a = new Class1<"conststr">();

[Korporal]

@4creators

This is extremely interesting and could well serve as the basis for implementing this much more easily:

#2099

We could create what we want "out of the box" using this feature if it gets traction.

Incidentally I wonder if the "const" is redundant here in that the language would no doubt insist it be a compile time constant anyway?

[hez2010]

FYI I have implemented a prototype of this feature for CoreCLR, you can already try out const generics today: dotnet/runtime#89636

[hez2010]

Hey everyone, I've implemented a full working coreclr runtime and C# compiler to support this feature.

And I've successfully made an SDK for it, so you can build and run your code directly just use Visual Studio or Visual Studio Code.
If anyone wants to try it, you can download the SDK, VS extensions and the language server here: https://1drv.ms/u/s!ApWNk8G_rszRgrxP32IMKhW-V8iWug?e=JBn8wU

Please do follow the README.txt.

My implementation supports the below things:

1. Declare a const generic type, eg. class Foo<T, int N>.
2. Use a const generic type, eg. new Foo<int, 42>().
3. Declare a const generic method, eg. void Foo<int X>.
4. Use a const generic method, eg. Foo<42>().
5. Generics on const type parameter, eg. class Foo<T, T X>, then you can use it with Foo<int, 42> as well as Foo<float, 42.42424f>.
6. Use const type parameter as constant directly. eg. calling Console.WriteLine(X) in the type class Foo<int X>.
7. typeof support. eg. typeof(42).
8. Casting support in const type argument. eg. new Foo<(short)42>, typeof((short)42)
9. A built-in value type ValueArray<T, int X> that can be used as a fix-sized type with type T and length X.
10. A niche syntax for declaring a ValueArray type, eg. int[42].
11. Full reflection support.
    • To check whether a type parameter is const type parameter, use type.IsGenericParameter && type.HasElementType.
    • To get the type of a const type parameter, use type.GetElementType().
    • To check whether a type argument is const type argument, use type.IsConstValue.
    • To get the type of a const type argument, use type.GetElementType().
    • To get the value of a const type argument, use type.ConstValue.
    • To make a const value type, use Type.MakeConstValueType()

UPDATE on 2023/9/1: Fix a bug that can cause stackoverflow while you using generics on const type parameter.