Allow ReadOnlySpan Attribute constructor arguments

[RenderMichael]

Especially with params ReadOnlySpan<T> incoming in .NET 9, it would be nice to have a non-allocating (less-allocating?) way to specify an array of values in an attribute. Today, an array needs to be materialized. Maybe a span here would allow less allocations for the same effect?

This may be achievable by allowing attributes to have {params} ReadOnlySpan<T> constructor arguments. The same rules would likely need to apply as for array arguments.

Example

public class Model
{
    [My(null, "abc", 123)] public object MyValues { get; set; }
}

public class MyAttribute : Attribute
{
    private List<object?> _parsedValues;

    public MyAttribute(params object?[] rawValues) // allowed today
    {
        ArgumentNullException.ThrowIfNull(rawValues);
        _parsedValues = ValidateAndParse(rawValues.AsSpan());
    }
    public MyAttribute(params ReadOnlySpan<object?> rawValues)
    {
        _parsedValues = ValidateAndParse(rawValues);
    }

    private static List<object?> ValidateAndParse(ReadOnlySpan<object?> rawValues)
    {
        // ...
    }
}

[huoyaoyuan]

The compiled format of attribute belongs to dotnet/runtime. It can only be utilized by C# if the format is decided, and the runtime supports loading such attribute.

[RenderMichael]

Spans don't necessarily point to the stack. They can point to heap memory (as in, array.AsSpan()) or even to data directly in the .data section of the assembly. You can get that by doing this:

class C
{
    public static ReadOnlySpan<int> MyValues => [1, 2, 3];
}

I imagine what I'm proposing could be done similarly.

[KennethHoff]

I get that they can point to items that aren't necessarily on the stack, but the Span itself is always allocated on the stack

[RenderMichael]

For an attribute like [My([1, 2, 3])], there could be a segment of memory containing those three values, and whenever an attribute gets instantiated, a span could be created to point to those values.

The main problem this is solving is the allocation of a new array for any array attribute parameter (a problem that's inevitable given the writeable nature of arrays). Using spans could allow the runtime to cache the same data for re-use.

[colejohnson66]

Do attributes even allocate at runtime if you never read them? I figured the runtime would lazily read them from the binary.

[RenderMichael]

They shouldn't, this would only move the needle if an attribute it being read multiple times. Arrays in attribute parameters aren't CLS-compliant anyway, though they are around.

[HaloFour]

I'd honestly think that the cost associated with allocating an array for an attribute would be miniscule compared to the reflection to interpret the custom attributes.

[RenderMichael]

Ah, well. If a value proposition can't be formed around this, then there's no real point. It feels nice to use spans though, and it would be part of that "peanut butter". But if it's not worth the investment (understandable, especially given runtime changes) then it shouldn't be prioritized.

I'm glad this possibility was considered.