Generic CollectionBuilderAttribute

[KennethHoff]

I originally wrote this in the Collection Literals proposal, but I was recommended to post it here instead, which makes sense, as this an implementation detail.

(Copy-pasted from that thread):

This a nit-pick - which might've been answered previously, but I couldn't find it.. but I also wrote this on my phone, so might've just missed it - but I'm wondering about the reasoning behind it, as it seems to be a recurring theme that new language features(with runtime changes) aren't really being used in any official capacity (Generic Attributes, Default interface Members, Static Abstract Interface Members). It al almost feels like a "why even bother implementing it" kind-of scenario.

We seem to be finalizing on the CollectionBuilderAttribute which has a constructor with a Type-, and a string parameter. Is there a reason this is not a generic Attribute? This seems like the perfect use-case

namespace System.Runtime.CompilerServices
{
    [AttributeUsage(
        AttributeTargets.Class | AttributeTargets.Struct | AttributeTargets.Interface,
        Inherited = false,
        AllowMultiple = false)]
    public sealed class CollectionBuilderAttribute : System.Attribute
    {
        public CollectionBuilderAttribute(Type builderType, string methodName);
        public Type BuilderType { get; }
        public string MethodName { get; }
    }
}

vs

namespace System.Runtime.CompilerServices
{
    [AttributeUsage(
        AttributeTargets.Class | AttributeTargets.Struct | AttributeTargets.Interface,
        Inherited = false,
        AllowMultiple = false)]
    public sealed class CollectionBuilderAttribute<T> : System.Attribute
    {
        public CollectionBuilderAttribute(string methodName);
        public string MethodName { get; }
    }
}

[jnm2]

I would really like to be able to make use of collection literals on older runtimes which don't support generic attributes. I believe the plan for the netstandard2.0 System.Collections.Immutable package is to use this attribute.

[stephentoub]

aren't really being used in any official capacity (Generic Attributes, Default interface Members, Static Abstract Interface Members)

Static abstract interface methods are being used in a significant capacity: the entire generic math feature introduced in .NET 7 is heavily based on them, they're at the center of code reduction techniques throughout multiple critical components (e.g. many of the span-based processing routines, SslStream, etc.)

Default interface members are also used, just not as heavily due to concerns about the diamond problem when they're added to very core interfaces.

And there are generic attributes in public surface area, e.g. https://learn.microsoft.com/en-us/dotnet/api/system.runtime.interopservices.marshalling.comexposedclassattribute-1?view=net-8.0, we just haven't had a strong need for many.

We seem to be finalizing on the CollectionBuilderAttribute which has a constructor with a Type-, and a string parameter. Is there a reason this is not a generic Attribute?

Because the benefit of it being a generic vs a type argument is very minor compared to losing downlevel support.

[jrmoreno1]

@stephentoub : as someone with a significant net48 code base, that sounds great, but that bus has sailed: the language version is tied to the runtime. I can use unsupported features that are just compiler magic, but it’s officially unsupported. C#12 will presumably be 8 or 9 only depending on when it comes out.

[stephentoub]

it’s officially unsupported

Yes, but significant codebases depend on it... including the C# compiler itself.

[Joe4evr]

In addition to Stephen's answer, another problem with CollectionBuilderAttribute<T> is that generic arguments aren't allowed to be static types (which is where an external factory method is usually expected) which makes it less useful than the version that takes a typeof expression.