[Draft Proposal]: Const Generics

[hez2010]

Const Generics

• Proposed
• Prototype: Done
• Implementation: Not Started
• Specification: Not Started

Summary

Const Generics is a feature that allows constant value to be used in a generic parameter or argument.

Motivation

This feature comes from the need of a type-safe and guaranteed constants.

Const Generics enables the use cases where developers need to pass a const value through a type parameter.

Typical use cases are templating for things like shuffle (its basically a guaranteed constant)
as well as for numerics, tensors, matrices and etc.

For example, fixed buffer and vector types [1], jagged arrays/spans [2], constrained shape of arrays [3], numeric types and multiplier types especially in graphics programming [4], expression abstractions [5], and value specialization [6].

For [1], we can have a type struct ValueArray<T, int N> to define a type of array of T with N elements.
This can also be useful in variadic parameters. For example, a params ValueArray<int, 5> can represent a variadic parameter that receives only 5 int arguments.
Beside, we can also leverage the ValueArray<T, int N> type to implement params {ReadOnly}Span<T>.

For [2], we can use the const type parameter to define a Span<T, int Dim>, so we can use Span for multi-dimension arrays as well.

For [3], we can constrain the shape of an array. This is especially useful when you are dealing with matrix or vector computations.
For example, you now can define a matrix using class Matrix<T, int Row, int Col>. When you implement the multiplication algorithm, you can simply put a signature Matrix<T, Row, NewCol> Multiply<NewCol>(Matrix<T, Col, NewCol> rMatrix). This can make sure users pass the correct shape of the matrix while doing multiplication operations.

For [4], we can embed the coefficient into a multiplier type. This is especially useful in graphics programming. For example, when you are working with things about illumination, you will definitely want some multiplier types with coefficients (which are basically floating point numbers) that are guaranteed to be constants. While building AI/ML models, we are also often use such constant coefficients.
Also, we will be able to create a floating point type with user specified epsilon, such as

struct EpsilonFloating<T, T Epsilon> where T : INumber<T>
{
    public static bool operator ==(EpsilonFloating<T, Epsilon> a, EpsilonFloating<T, Epsilon> b) => T.Abs(a.value - b.value) <= Epsilon;
}

and then use it like global using MyFloatWithEpsilon = EpsilonFloating<float, 1e-6f>.

For [5], we can have several types that can embed constant values to abstract an expression, then we can validate the expression at compile time, hence no runtime exception will happen. For instance, we can have below interface types:

• abstract class BinOp
• sealed class AddOp : BinOp
• sealed class MulOp : BinOp
• interface IExpr
• interface IConstExpr<T, T Value> : IExpr
• interface IBinExpr<TOp, TLeftExpr, TRightExpr> where TOp : BinOp where TLeftExpr : IExpr where TRightExpr IExpr

Then we can use IBinExpr<MulOp, IBinExpr<AddOp, IConstExpr<int, 42>, IConstExpr<int, T>>, IConstExpr<int, 2>> in a type class Foo<int T> to represent 42 * (T + 2), then we can use it like a type and let the compiler to verify whether the given const type argument satisfies the expression or not.

For [6], we will be able to provide a generic Vector type and specialize SIMD-width types with extensions:

struct Vector<T, int Size> { }

static class VectorExtension
{
    public Vector<int, 4> Multiply<T>(this Vector<int, 4> v, Vector<int, 4> right) { } // Vector64
    public Vector<int, 8> Multiply<T>(this Vector<int, 8> v, Vector<int, 8> right) { } // Vector128
    public Vector<int, 16> Multiply<T>(this Vector<int, 16> v, Vector<int, 16> right) { } // Vector256
    public Vector<int, 32> Multiply<T>(this Vector<int, 32> v, Vector<int, 32> right) { } // Vector512
    public Vector<int, Size> Multiply<int Size>(this Vector<int, Size> v, Vector<int, Size> right) { } // For other sizes allowing a software fallback
    // ...
    public Vector<T, Size> Multiply<T, int Size>(this Vector<T, Size> v, Vector<T, Size> right) { } // For other types and sizes allowing a software fallback
}

Detailed design

Wording

• Const type parameter: a type parameter that carries a const value.
• Const type argument: the constant value for a type parameter in the instantiation.

Const type parameter

A const type parameter is, a type parameter that will carry a constant value of a specified type.

To declare a const type parameter, we use the syntax:

type_parameter
  : attribute_list* ('in' | 'out')? type? identifier_token

For example, a int T represent a type parameter T that has constant value of type int, while a T Value represent a type parameter Value that has constant value of type T.

The type of a const type parameter can be: bool, byte, sbyte, char, ushort, short, uint, int, ulong, long, float, double or the type declared by a generic type parameter (see the section "Generics on const type parameter" below).

Const type argument

A const type argument is, a constant value that will be passed to a const type parameter.

We use the following syntax to define a const type argument:

type
  : literal_type_argument
  ;

literal_type_argument
  : literal_type_argument_expression
  ;

literal_type_argument_expression
  : literal_type_argument_cast_expression
  | literal_type_argument_simple_expression
  ;

literal_type_argument_cast_expression
  : '(' predefined_type ')' expression
  ;

literal_type_argument_simple_expression
  : 'false'
  | 'true'
  | character_literal_token
  | numeric_literal_token
  ;

Note that we use literal instead of const in the syntax tree because we are already using literal keyword in the metadata to represent a constant value.

For example, a 42 represents an int const type argument with value 42, a 42.42f represents a float const type argument with value 42.42, a true represents a bool const type argument with value true, and a (short)42 represent a short const type argument with value 42.

ValueArray

We added a type struct ValueArray<T, int N> in the BCL to represent a fix-sized array type that can be allocated on the stack.

So we can support a niche syntax that can have fixed size on an array to be emitted as a System.ValueArray:

int[42] array = new();

which is the same with System.ValueArray<int, 42> array = new().

This can be used together with params as well:

Foo(1, 2, 3, 4, 5);
// a method that only receives 5 int arguments
void Foo(params ValueArray<int, 5> args) { }

Particularly, in C# we can lower all fixed buffer types to ValueArray, and it can perfectly serve all features like params Span<T> and stackalloc T[].

Generics on const type parameter

This is useful because we don't allow overloading over generic constraints, so if the type of a const type parameter cannot be determined in advance, we need generics on it to leave the decision to end users.

var intValue = new ConstValue<int, 42>();
var floatValue = new ConstValue<float, 42.42f>();
var boolValue = new ConstValue<bool, true>();
var shortValue = new ConstValue<short, (short)42>();

struct ConstValue<T, T V>
{
    public Type Type => typeof(T);
    public T Value => V;
}

Const value type

Due to the above changes, we will support const value as a type. But we don't want to support the general literal types that can be used without a type argument context, so we only support use const value as a type in typeof context, in order to support reflection.

void Foo(42 v) { } // error: we don't support using literal value type without a type argument context
void Foo(C<42> v) { } // ok
typeof(42) // ok

This is saying that we can use typeof(value) to create a runtime type handle that holds the constant value, so we can use it later in MakeGenericType and MakeGenericMethod purpose.

Generic constraint over const type parameters

We can add the generic constraint support for const type parameters, so the value of a const type parameter can be constrained to avoid incorrect input.

This will allow us to write expressions with type parameters and const values as a type directly.

For instance,

class Foo<int T, int U, int V> where V : == T + U where T : != 0

Then we will be able to check the generic constraint with given instantiation at compile time, for example, new Foo<1, 2, 3> will be accpected, while new Foo<1, 2, 4> and new Foo<0, 1, 1> be will rejected.

Type const argument usesite

We allow a type const argument to be used as an R-value directly.

Therefore, we can use Console.WriteLine(X) in a method void Foo<int X>().

Lookup

We look up the members of a const type parameter by treating it as the type of the const type parameter.

For example, if we have a const type parameter int T, then T will have a type int in any usesite, hence the members of T are exactly the members of int.

So T.ToString() will be resolved as an instance call to int.ToString.

Overload resolution

We treat different const type arguments as distinct types in overload resolution. Assuming we have a type class Foo<T V>, then we will take the constant value into account in overload resolution:

int Bar(Foo<int, 1> foo) => 1;
int Bar(Foo<int, 2> foo) => 2;
int Bar<int V>(Foo<int, V> foo) => 3;
int Bar(Foo<float, 1> foo) => 4;
int Bar(Foo<float, 2> foo) => 5;
int Bar<float V>(Foo<float, V> foo) => 6;
int Bar<T, T V>(Foo<T, V> foo) => 7;

Bar(new Foo<int, 1>()); // 1
Bar(new Foo<int, 2>()); // 2
Bar(new Foo<int, 3>()); // 3
Bar(new Foo<float, 1f>()); // 4
Bar(new Foo<float, 2f>()); // 5
Bar(new Foo<float, 3f>()); // 6
Bar(new Foo<bool, true>()); // 7

Lowering

Generic constraint on const type parameters

To lower the expression of a generic constraint, we need some types defined in System.Runtime.CompilerServices that can be used to build an expression in a type so that we can use it for generic constraints.

namespace System.Runtime.CompilerServices;

public abstract class Operator
{
    public abstract class UnaryOperator : Operator 
    {
        // ...
    }
    public abstract class BinaryOperator : Operator
    {
        public sealed class AdditionOperator : BinaryOperator { }
        public sealed class SubtractionOperator : BinaryOperator { }
        public sealed class MultiplyOperator : BinaryOperator { }
        public sealed class DivisionOperator : BinaryOperator { }
        public sealed class EqualityOperator : BinaryOperator { }
        public sealed class LessThanOperator : BinaryOperator { }
        public sealed class DisjunctionOperator : BinaryOperator { }
        // ...
    }
}

public interface IExpression
{
    public interface IConstantExpression<TValue, TValue Value> : IExpression { }

    public interface IUnaryExpression<TOperator, TOprand> : IExpression where TOperand : IExpression where TOperator : UnaryOperator { }

    public interface IBinaryExpression<TOperator, TLeft, TRight> : IExpression where TLeft : IExpression where TRight : IExpression where TOperator : BinaryOperator { }
    // ...
}

Note that they are special types that are not being implemented by any types. It's an implementation detail and we special case those type for verifying generic constraint purpose only.

For the case where V : == T + U where T : != 0, it will be lowered to:

where T : 
    IBinaryExpression<
        EqualityOperator,
        IBinaryExpression<
            DisjunctionOperator,
            IBinaryExpression<
                LessThanOperator,
                IConstantExpression<int, T>,
                IConstantExpression<int, 0>
            >,
            IBinaryExpression<
                LessThanOperator,
                IConstantExpression<int, 0>,
                IConstantExpression<int, T>
            >
        >,
        IConstantExpression<bool, true>
    >

where V :
    IBinaryExpression<
        AdditionOperator,
        IConstantExpression<int, T>,
        IConstantExpression<int, U>
    >

Then we can compute the expression at compile-time to make sure users pass the right value.

Emitting

Const type parameter

We can treat the type of a const type parameter as a special generic constraint.

We want to emit the type of a const type parameter as TypeSpec, but in order to distinguish this type token from other generic constraints, we introduced a mdtGenericParamType and then emit the type of const type parameter with mdtGenericParamType, and make sure it will always be the first entry in generic constraints.

Const type argument

We added an element type ELEMENT_TYPE_CTARG standing for const type argument, while emitting a const type argument in the signature, we simply emit ELEMENT_TYPE_CTARG Type Value in the signature.

For instance, a 42 can be emitted as ELEMENT_TYPE_CTARG ELEMENT_TYPE_I4 42.

Const type parameter use sites

When reference a const type parameter, we use ldtoken to load the const type parameter. The JIT compiler in the runtime will import the value as a constant directly, which has the same result with using ldc.* instructions that produce a constant value.

class C<int T>
{
    void M()
    {
        // ldtoken !T
        // ldc.i4.1
        // add
        var x = T + 1;
    }
}

typeof(value) in context other than attributes

We add a Type.MakeConstValueType(object? value) to make a type of a constant value.

So, typeof(42) will be emitted as Type.MakeConstValueType(42), while typeof(T) where T is a const type parameter, will be emitted as Type.MakeConstValueType(T).

typeof(value) in attributes context

We need to emit the type name while emitting typeof on an attribute. Here we use the metadata type representation Type (hex value), Assembly to represent a const value type.

For instance, the type name of 42 in typeof(42) that is in an attribute context [Attr(typeof(42))] will be emitted as System.Int32(0x2a), System.Runtime, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3ad, while a 42.42 will be emitted as System.Double(0x4045364d7f0ed3d8), System.Runtime, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3ad.

It's important to have the const value to be emitted as hex string representation because this can make sure we can always get the accurate value from the string representation.

Proposal for the runtime and IL

See dotnet/runtime#89730

Fully Working Prototype

This prototype is based on the old design with a breaking change to the metadata, while the latest (current) design doesn't have any breaking changes to the metadata

I have done the fully working prototype of C# compiler, language server and CoreCLR runtime, and successfully built a SDK for it (Windows only).

If you want to have a try on const generics, you can download the SDK here: https://1drv.ms/u/s!ApWNk8G_rszRgrxP32IMKhW-V8iWug?e=JBn8wU

Be sure to follow the README.txt in the SDK.

Version: 20230912 Build 1
Checksum: a8c9ee29d1accd14797f60bedced312f9524391b

This prototype branch:

• Roslyn: https://github.com/hez2010/roslyn/tree/feature/const-generics
• Runtime: https://github.com/hez2010/runtime/tree/feature/const-generics-managed

I may update the SDK without posting a new comment but change the version and checksum in the above, while the sharing link won't change.

This prototype supports all things in this proposal except generic constraints on const type parameter and const arithmetic.
For example, you can do the following 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()

Drawbacks

• Making the type system more complex

Alternatives

• Not doing this and instead creating all variants of type that has the value hard coded in it: this would make the library extremely bloated and non-extensible
• Emit unspeakable internal types with hard coded const values: this would make the type impossible to be exposed in public APIs, because even if two types from different assemblies have the same constant value hard coded, they are still different types and are not compatible with each other.

Unresolved questions

Generic constraint on const type parameters emitting

Should we use modreq or something else to emit the generic constraint on const type parameters? Because those expression types are actually not being implemented by any types, but we still use them in the generic constraints which let them look like interface constraints but behave as expression evaluation, which is not intuitive.

For example, we can add something like constexpr constraints in the metadata and allow it to be emitted directly, so class Foo<T, U, V> where V : == T + U where T : != 0 can be represented in IL as:

.class public auto ansi beforefieldinit Foo<literal int32 (constexpr (!T != int32 (0))) T, literal int32 U, literal int32 (constexpr (!V == !T + !U)) V>

Const arithmetic

We want to support const arithmetic as well, so we can define a type that has an arithmetic relation to an existing const type parameter:

Vec<T, N + 1> Push<T, int N>(Vec<T, N> vec, T value) { }

It's useful to have arithmetic support for const generics.

For example, the signature of a Push method of ValueArray<T, int N> type can be ValueArray<T, N + 1> Push(T elem), and the signature of a Concat method can be ValueArray<T, N + M> Concat<int M>(ValueArray<T, M> elems).

This would require embedding the arithmetic operations in the type and implementing dependent/associated types, which is a non-trivial work.

While an alternative is to use constraints to achieve it. So for the example of Push method, we can use ValueArray<T, U> Push<int U>(T elem) where U : (T + 1), and the constraint T + 1 can be expressed using IBinaryExpression<Add, IConstantExpression<int, T>, IConstantExpression<int, 1>>. Then we can validate the constraint at runtime.

Although we need to specify the value such as Push<7>(42) while calling on ValueArray<int, 6>, the compiler may automatically infer the type of U so developers don't have to explicitly specify the value of U every time.

However, consider the below code:

class Foo<int T>
{
    private Foo<T + 1> foo;
}

Are we going to enforce users to introduce a new type parameter on Foo? I.e.,

class Foo<int T, int U> where ...
{
    private Foo<U> foo;
}

If yes, whenever we want to introduce a new "computed" const type parameter on a method of the class, we will need to add it to the class signature, which will lead to breaking changes. This seems quite unfortunate, and unacceptable.

Therefore, we cannot just rely on generic constraints to serve const arithmetic.

However, if we have runtime support for dependent/associated types in the future, this can be simply resolved by using:

class Foo<int T>
{
    type N = T + 1;
    private Foo<N> foo;
}

And also, if we have the support for defining an associated type inside a method, we can do:

class Foo
{
    U Method<int T>()
    {
        type U = T + 1;
    }
}

We still need some discussion to design around here.

Maybe we can just skip const arithmetic for the first version, and implement const arithmetic in the future once we have proper runtime support?

More flexible const type argument emitting

The current const type argument emitting strategy limits the const type argument to be primitive types only, while actually we may want to support arbitrary value types too (considering System.Half, System.Int128 and etc.)

Thus we may want to change the emitting strategy to be ELEMENT_TYPE_CTARG <type-token> <constant-token> instead.

[yuyang9119]

Because of dupe they close my idea, so I paste here:

I just saw this: #7508, it is a great proposal, but before reading it, I thought of a simple syntactic sugar, no need to modify the existing type system. The example code is roughly as follows.

    // Example ////////////

    class UserType<T1, int X, T2, int Y> { }
    void Func() => new UserType<string, 5, float, 16>();


    // Translated ////////////

    // This is a built-in interface
    interface IConstIntGeneric { abstract const int Value; }

    class UserType<T1, TGen1, T2, TGen2>
        where TGen1 : IConstIntGeneric
        where TGen2 : IConstIntGeneric
    {
        const int X = TGen1.Value;
        const int Y = TGen2.Value;
    }

    struct Gen_int_5 : IConstIntGeneric { public const int Value = 5; }
    struct Gen_int_16 : IConstIntGeneric { public const int Value = 16; }

    void Func() => new UserType<string, Gen_int_5, float, Gen_int_16>();

As you can see, it almost exclusively uses the existing C#, except for abstract const. When x and y are applied to the generic parameter, they are replaced with the generated struct; otherwise, they are treated as constants inside the user type.

This idea was inspired by abstract static, which is mainly used in conjunction with generics, and the same goes for abstract const. But constants are determined at compile time, while static variables are not. We know that constructed generics are also determined at compile time, and abstract const has linked generics and constants together. So, by this syntactic sugar, we can merge them into the same thing. If constants can be used as types, they can be passed as generic parameters like types, thus achieving code sharing. For example, we can create something like InlineArray<T, int size>.

[EDIT] Maybe we can let the user decide whether to expose the constant, like this:
class UserType<T1, private int X, T2, public int Y> { }
Puplic constants might be helpful for programming, as it can avoid hard coding in outside code. But I'm not sure, should the default access modifier be private or public?

[yuyang9119]

I'm sorry for my description not being precise enough. What I meant is that the kind of generics where a programmer passes a specific type in the code can be discovered at compile time, just like constant expressions can be analyzed.

Of course, this might not be sufficient because generics can also be "synthesized" at runtime, and if such generics are not supported, it might impose limitations on their use. I'm not familiar with this technology, but I speculate that it should be achievable since generics be constructed at runtime (with variable sizes of 'T'), so constant generics would likely just add some additional complexity to the system... maybe?

[theunrepentantgeek]

What I meant is that the kind of generics where a programmer passes a specific type in the code can be discovered at compile time, just like constant expressions can be analyzed.

This can already be done.

Assuming T is a type parameter that's in scope, then typeof(T) is a valid expression that resolves to whatever type the programmer has passed, regardless of whether the generic type was defined at compile type or synthesized at runtime.

Moreover, the JITter treats this as a constant expression, such that comparisons of the form typeof(T) == typeof(int) resolve to a constant true or false that's further optimized. This technique is used in some of the core .NET libraries to provide optimal implementations for some well known use cases.

So, as far as the descriptions you've given so far, this feature is already present.

[yuyang9119]

This is interesting, I thought there were technical issues to be solved with abstract const. So, in my idea of abstract const, the only obstacle to its implementation is in the syntax? If the language can support abstract const, then there would be no obstacle to implementing const generic with syntactic sugar.

[HaloFour]

Neither the language nor runtime have a concept of abstract const. Constants aren't members, let alone virtual. They are a literal value that doesn't exist at runtime. They require the compiler to resolve and to replace callsites with the literal value at compile time. This proposal would require that the runtime be able to resolve these non-existent members to constants, and to be able to apply them to attributes or other scenarios as constants. I'd expect it'd be as expensive, if not moreso, to implement this hack over just doing it right.

[CyrusNajmabadi]

So, in my idea of abstract const, the only obstacle to its implementation is in the syntax?

No. The obstacle is there is no mechanism whatsoever to do what you're asking for. A mechanism would have to created to solve exactly this (which is what this proposal actually demonstrates how you would do things).

Constants have their values known at compile time, and are directly utilized at their use site location. This is not at all like abstracts (or statics). You can't just say that this will be "solved with abstract const" as you haven't even shown what it means, or how it would work in the first place.

This is heavily contrasted with this proposal, which does the legwork to actually writeup all the semantics and demonstrate how both the language and runtime would support this.

[yuyang9119]

So, in my idea of abstract const, the only obstacle to its implementation is in the syntax?

No. The obstacle is there is no mechanism whatsoever to do what you're asking for. A mechanism would have to created to solve exactly this (which is what this proposal actually demonstrates how you would do things).

Constants have their values known at compile time, and are directly utilized at their use site location. This is not at all like abstracts (or statics). You can't just say that this will be "solved with abstract const" as you haven't even shown what it means, or how it would work in the first place.

This is heavily contrasted with this proposal, which does the legwork to actually writeup all the semantics and demonstrate how both the language and runtime would support this.

I almost completely agree with what you said. It is because of this proposal that I believe abstract const can be achieved, even though its original purpose was for implementing const generics. As I mentioned in my idea, this is a great proposal and covers many aspects I haven't thought about, such as generic constraints.

However, I still believe in presenting my idea because I think combining this proposal with my idea might work better. abstract const can offer more possibilities, and implementing const generics through abstract const is easily understandable. For example, if you obtains a Type, you only need to check whether it implements the IConstIntGeneric interface to determine if it is a const generic.

So, what is abstract const? We already know the value of abstract static, but abstract static still has some limitations, such as not being used as parameters for attributes (so it can't be passed as a parameter to InlineArrayAttribute), can't be used to create any other constants (can't be used in constant expressions), and can't be used for certain compile optimizations (the compiler can't determine that it won't change).

For example, consider IMinMaxValue, which provides static properties, but int.MaxValue and int.MinValue were originally constants, which narrows the usage scenarios of T.MaxValue and T.MinValue in generic contexts.

Here is another example (discussion in runtime: BitCount of IBinaryInteger):

    struct InlineCollection<TItem, TMask> where TMask : IBinaryInteger<TMask>
    {
        TMask _availableMask = TMask.AllBitsSet;

        // Should be inline array
        TItem[] _buffer = new TItem[Capacity];

        // Should be const
        public static int Capacity => TMask.Zero.GetByteCount() * 8;

        public bool IsFull => _availableMask == ~TMask.AllBitsSet;
        public bool IsEmpty => _availableMask == TMask.AllBitsSet;
        public int Count => Capacity - int.CreateTruncating(TMask.PopCount(_availableMask));
    }

In this example, I attempt to implement a collection where the capacity is determined by the number of binary bits in TMask. TMask is likely to be a short, int or long. Because it uses a field of type TMask to record which positions are available, it doesn't need to move a large number of elements every time an element is removed, as List does, to avoid gaps in the middle of the array. Since TMask.TrailingZeroCount has hardware support, finding available positions is very fast. However, due to the absence of abstract const, TMask cannot provide a constant size, which further makes it impossible for _buffer to be an inline array.

[tannergooding]

For example, consider IMinMaxValue, which provides static properties, but int.MaxValue and int.MinValue were originally constants, which narrows the usage scenarios of T.MaxValue and T.MinValue in generic contexts.

These wouldn't have been C# constants even with the existence of such a hypothetical abstract const feature, because IMinMaxValue must support types which cannot have constants.

The JIT is perfectly capable of treating such simple static properties as JIT constants and will optimize the native code it emits accordingly.

[yuyang9119]

Yes, IMinMaxValue, as a common interface, should not provide constant properties. To address this, a new interface, such as IFixedMinMaxValue, can be added to retain all the characteristics of the actual type corresponding to generics as much as possible.

[tannergooding]

It is very unlikely that we would define such an interface. We have IMinMaxValue already and it is not worth defining a nearly identical interface whose only purpose is to support the primitive types in a scenario where the JIT already does the right thing and covers at least 95% of the everyday considerations.

[yuyang9119]

While compilation can optimize, it cannot overcome syntactical limitations. The primary purpose of adding new interfaces is to enable code, similar to the example in my case, to compile successfully. I just need to add an additional generic constraint like this: where TMask : IFixedSizeNumber.

[yuyang9119]

It is very unlikely that we would define such an interface. We have IMinMaxValue already and it is not worth defining a nearly identical interface whose only purpose is to support the primitive types in a scenario where the JIT already does the right thing and covers at least 95% of the everyday considerations.

Possibly fixed-size interfaces should implement variable-size interfaces, which is reasonable and avoids creating two parallel sets of interfaces, just like this:

    public interface INum<T> where T : INum<T>
    {
        abstract static T MaxValue { get; }
        int ByteCount { get; }
    }

    public interface IFixedSizeNum<T> : INum<T> where T : IFixedSizeNum<T>
    {
        abstract const T FixedMaxValue { get; }
        abstract const int FixedByteCount { get; }

        // It would be best if it could be implemented here
        static T INum<T>.MaxValue => T.FixedMaxValue;
        int INum<T>.ByteCount => T.FixedByteCount;
    }

[tannergooding]

This would still double the number of interfaces and is not something we're interested in doing or providing.

It likewise would still not be suitable for the scenario you're trying to make it usable for. A type such as Int128 is fixed sized, but does not support const.

[msedi]

What I would really love to see is to allocate structs like this:

public readonly ref struct FixedStruct<T, size> where T : struct where size : const int
{
    public readonly Span<T> Value = stackalloc T[size]
}

But I could also live with this

public readonly ref struct FixedStruct<T> where T : struct
{
    public readonly Span<T> Value;
    public FixedStruct(int size)
    {
        Value = stackalloc byte[size];
    }
}

The problem is that I cannot define the the struct size dynamically which would be very helpful to have struct-based vectors of predefined length in high-performance environments. Current, from what I know I can only define the struct size having differently sized variants of it, like Vector2, Vector3, Vector4, etc.

It would be nice if the stackalloc would be some part of the struct's total size. To my knowledge structs are currently very strict in their size definition can cannot change once defined, right?

See: dotnet/runtime#94832

[AhmedZero]

I hope it will be in .NET 9.