Permit usage of attribute constructors with nullable versions of literal-able structs

[Rekkonnect]

Currently, using an attribute constructor with int? or similar is prohibited. Specifically, for all the available constant value types, the compiler will prohibit their usage (byte, sbyte, short, ushort, int, uint, long, ulong, float, double, bool, char, and any enum type).

Since the nullable versions of the structs that support constant literals are also literals, this could be enabled as a feature.

From this answer on StackOverflow:

This is a CLR restriction. Only primitive constants or arrays of primitives can be used as attribute parameters. The reason why is that an attribute must be encoded entirely in metadata. This is different than a method body which is coded in IL. Using MetaData only severely restricts the scope of values that can be used. In the current version of the CLR, metadata values are limited to primitives, null, types and arrays of primitives (may have missed a minor one).

This justifies the current restriction, however it could be worked around. Since the metadata supports holding instances of the types object, string, Type and arrays of any other allowed types, a reference to the constant value could also be held to support those types as well. I'm assuming that those reference types are stored as pointers to the addresses that the values are held, in which case any other reference type could be permitted, for long as it would support a constant expression representing it.

Side-effects

• With this change, decimal could also see a bright day.
• Constant expressions can be "upgraded" to also support nullable struct constants being assigned (i.e. const int? a = 4; is currently unavailable).

[alexrp]

I'm assuming that those reference types are stored as pointers to the addresses that the values are held, in which case any other reference type could be permitted, for long as it would support a constant expression representing it.

Your understanding of how object, string, and Type are encoded is incorrect; they are unfortunately not that flexible. See Ecma 335, II.23.3.

The rules for CA encoding could probably be expanded if need be, but as they are now, you can't encode int?, decimal, etc and expect it to work at run time or with arbitrary tooling.

[Rekkonnect]

I just looked at the spec at the paragraph you specified, and you're right. The encoding rules will have to be expanded in a number of ways to properly support constant expressions. Worse yet, from what I can tell, strings with more than 254 characters are not supported, which can be an issue in very specific cases. This means there's room for improvement on this part of the runtime.

[ufcpp]

see dotnet/csharplang#4814 dotnet/csharplang#2878 dotnet/csharplang#688

[Rekkonnect]

These are all related together but not bound to this specific case. A champion issue covering this whole area would be much more appropriate.

[MgSam]

I think the current scenario around nullable value types and Attributes are a mess. There is no compiler warning or error (or analyzer) for putting nullable value type properties in an Attribute. It will just silently fail until such time when users go to use the attribute (since such properties cannot be assigned to).

We produce a library for others to consume that includes attributes and have been bitten by this repeatedly. Compounding the issue is we usually can't even fix such bugs easily, because changing the type of attribute after the fact is a binary compatibility change.

Nullable value types have been in C# since 2.0. They are a fundamental part of C# and work seamlessly everywhere else in the language. They absolutely should be expressible in Attributes.

[HaloFour]

Shouldn't this be moved to the runtime repository?

[HaloFour]

Here's the ECMA 335 CLI spec on custom attributes which does explicitly enumerate the supported types:

https://github.com/stakx/ecma-335/blob/master/docs/ii.23.3-custom-attributes.md

[MgSam]

Agree then someone should move this.

[333fred]

Done.

[HaloFour]

@333fred

Thanks!

Out of curiosity, what's your temperature on expanding the supported element types in custom attributes? I'd imagine there'd be no traction in the runtime if the C# team weren't interested in following up with a language change to also support those types.

[333fred]

My general feeling is that, while I'd be fine with it, I think cross-team efforts have more important things to work on 🙂.