Runtime constants in attributes

[timcassell]

Currently, attributes only allow compile-time constants as constructor arguments/properties. If we were allowed to use runtime constants, attributes would become much more powerful.

What is considered a runtime constant? Existing consts, obviously, but also any static readonly field (which the tier-1 JIT treats as consts), as well as static pure functions* and properties (e.g. IntPtr.Size), and constant expressions (e.g. IntPtr.Size * 2).

This would enable things like lambdas in attributes (dotnet/csharplang#343), improved explicit layouts (dotnet/csharplang#4652), enabling users to do things like

runtime/src/libraries/System.Private.CoreLib/src/System/Collections/Concurrent/ConcurrentQueueSegment.cs

Lines 339 to 344 in 7b1e788

	[StructLayout(LayoutKind.Explicit, Size = 3 * Internal.PaddingHelpers.CACHE_LINE_SIZE)] // padding before/between/after fields
	internal struct PaddedHeadAndTail
	{
	[FieldOffset(1 * Internal.PaddingHelpers.CACHE_LINE_SIZE)] public int Head;
	[FieldOffset(2 * Internal.PaddingHelpers.CACHE_LINE_SIZE)] public int Tail;
	}

and more.

---

We don't currently have a way to declare a pure function. There is an old csharplang discussion about it (dotnet/csharplang#776), probably it's a new thing that would require runtime validation of purity.

[KalleOlaviNiemitalo]

"Removing readonly from a field" would then become a breaking change, if the field is static.

[timcassell]

"Removing readonly from a field" would then become a breaking change, if the field is static.

Hm. Personally, I would be ok with that. But I understand how that would be troublesome for the ecosystem. What about annotating a static readonly field such that it will be considered a runtime constant, and removing that annotation will be a breaking change instead (it would be invalid to have the annotation on a non-readonly field)? A similar annotation could be used for the functions/properties as well.

[KalleOlaviNiemitalo]

Or perhaps it could be limited to static fields that are not accessible from outside the assembly; thus internal, private, or private protected. That way, removing readonly could not break third-party assemblies. Having to define internal static readonly IntPtrSize = IntPtr.Size; just for use in attributes would be a bit annoying though.

Then, I wonder about reflection APIs. For System.Reflection.CustomAttributeTypedArgument, it might suffice if the object? Value property just returned the runtime-constant value without indicating how it was obtained. This would not work with Assembly.ReflectionOnlyLoad (because the initialisation of the static field could not be executed) but .NET Core doesn't support that anyway. For System.Reflection.Metadata.CustomAttributeTypedArgument<TType> though, I think there should be a way to get the expression or at least the metadata token of the field.

[timcassell]

Actually, that might be just fine for the runtime to only support internal static readonly fields. The C# compiler doesn't have to have the same restriction, and could synthesize the field for you.

[acaly]

Or perhaps it could be limited to static fields that are not accessible from outside the assembly; thus internal, private, or private protected.

IMO it's not a good idea to add new meanings (or implications) to internal and others.

The C# compiler doesn't have to have the same restriction, and could synthesize the field for you.

This doesn't solve the breaking-change problem. The compiler may try to synthesize an internal static readonly from a public static readonly in another assembly. What if that readonly is removed? This will still be a valid program, but may give unpredictable results.

[timcassell]

The C# compiler doesn't have to have the same restriction, and could synthesize the field for you.

This doesn't solve the breaking-change problem. The compiler may try to synthesize an internal static readonly from a public static readonly in another assembly. What if that readonly is removed? This will still be a valid program, but may give unpredictable results.

Not having the same restriction doesn't mean the compiler must have no restrictions. It could have the requirement that used fields and properties be annotated with [RuntimeConstant], for example.

Also, even if that were to happen, I don't think it's a big deal. It would still be a runtime constant, evaluated only once.

[acaly]

Having [RuntimeConstant] is a much better choice IMO.

The point is not to allow arbitrary existing static readonly fields to be used in attributes (although they are treated as runtime constants by the runtime). This should be an opt-in feature. Only in this way the breaking-change problem can be solved.

In this case, is it possible to reuse the const keyword in C# to allow any type, effectively making them [RuntimeConstant] static readonly? This follows the recent trend of extending or redefining existing keywords for broader scenarios.

[hez2010]

Having [RuntimeConstant] is a much better choice IMO.

It's not about how the syntax will be; it's about that this proposal needs to change the metadata of attributes because today all attributes are required to be emitted as literal values in the assembly.