[API Proposal]: Rethink and implement use case of CS0416

[honzapatCZ]

Background and motivation

Currently using a generic inside an attribute is an illegal move and results in CS0416, this has been established very very long ago to keep the compiler simple. Given the current move to more reusable, readable code we should try to reevaluate the problem.

This currently required other hacky ways to pass the info or sometimes destroys a particular usecase completely.

API Proposal

[Attr(typeof(List))]

API Usage

public class Foo<T>
{
        [Attr(typeof(List<T>))]
        public void Get(T entity)
        {
            return entity;
        }
}

Alternative Designs

No response

Risks

Change to the compiler, albeit being only additive

[jkoritzinsky]

I'd also like to add my support to this idea. We have had to go to pretty significant lengths to work around this in the LibraryImport source generator and other interop source generator for our user-defined marshalling logic, and it would be very nice to be able to avoid propagating that design elsewhere.

[RikkiGibson]

I'd be curious to learn about this in more detail.

[CyrusNajmabadi]

Can you flesh out the example so it's something compilable except for the one thing you'd ike to work?

The title and OP should actually refer to the language rules, not compiler error codes. There's no way to know what this is referring to in isolation.

[333fred]

In order for this work, we'd need to have a way to encode the T here in metadata in the attribute constructor call. The format is defined in ECMA 335, II.23.3:

If the parameter kind is System.Type, (also, the middle line in above diagram) its value is stored as a SerString (as defined in the previous paragraph), representing its canonical name. The canonical name is its full type name, followed optionally by the assembly where it is defined, its version, culture and public-key-token. If the assembly name is omitted, the CLI looks first in the current assembly, and then in the system library (mscorlib); in these two special cases, it is permitted to omit the assembly-name, version, culture and public-key-token.

In other words, the type is encoded as a UTF-8 encoded byte array. This string has no ability to refer to several things, including the T from the containing type (it also can't refer to a function pointer type, for example). In order for this work best, we'd really like to be able to put a type token in this array, but that would require a small bit of changes in the runtime and a potentially large number of changes in tools that understand the runtime. This latter concern is what has blocked changes here in the past.

[TahirAhmadov]

Would it be possible to enhance the "syntax" of this string to allow the generic argument use case? And if it's possible, would that be more or less effort than the token approach?

[333fred]

In theory, but I think it would be nearly as deleterious as the token proposal, without any of the benefits.

[honzapatCZ]

would the later be a problem considering it being implemented in a major release?

[333fred]

I mean, as I said it's what blocked this change in the past.

[honzapatCZ]

Examaple that otherwise compiles

public class TestAttrAttribute<T> : Attribute
{
    T someItem;
}

public class Foo<T>
{
    [TestAttr<T>()]
    public void Test(T item)
    {

    }
}