Allow non-constant values in attributes

[JustNrik]

As the title suggests, it would be good if attributes allowed non-constant values. (Sorry if this is a duplicate but I try searching and I couldn't found a similar issue)

How would this be useful?

One thing I was thinking is that this would greatly improve NRT Analysis, for example:

public interface ICache<T> where T : class
{
    bool IsExpired { get; }
    T? Value 
    { 
        [return: NotNullWhen(IsExpired is false)]
        get; 
    }
}

In this example, we could expect ICache<SomeType>.Value not to be null is we previously check if IsExpired is true. Of course this example is really simple and can be worked-around by just nullchecking Value, but there could be other more complex use cases where this would be useful.

[333fred]

For this particular NRT case, C# 9 will have MemberNotNullWhen, used like this:

public interface ICache<T> where T : class
{
	[MemberNotNullWhen(false, nameof(Value)]
    bool IsExpired { get; }
    T? Value 
    {
        get; 
    }
}

[JustNrik]

For this particular NRT case, C# 9 will have MemberNotNullWhen, used like this:

public interface ICache<T> where T : class
{
	[MemberNotNullWhen(false, nameof(Value)]
    bool IsExpired { get; }
    T? Value 
    {
        get; 
    }
}

oh I wasn't aware of that, really nice!!!

[jnm2]

Is there any other C# issue asking for this? I'd like to be able to use syntax such as new DateTime(2020, 1, 1) for attribute arguments. It would make parameterized tests nicer.

ECMA-335 could be expanded so that an attribute argument could hold either an existing constant value or a reference to a static field, a constructor, or a non-void static method (including property and indexer getters) followed by argument values that are encoded the same way.

C# syntax could be expanded to allow static member accesses/invocations, tuple syntax, and object creation syntax. Object initializers could even be supported the same way if ECMA-335 allows named arguments to be encoded for them just like named arguments on the constructed attribute instance itself.

Perhaps System.Reflection.CustomAttributeData hands back a System.Linq.Expression for arguments like this, since these new capabilities would be a subset of that?

[Joe4evr]

Is there any other C# issue asking for this?

Here's one from back on roslyn: dotnet/roslyn#12377

Perhaps System.Reflection.CustomAttributeData hands back a System.Linq.Expression for arguments like this, since these new capabilities would be a subset of that?

Sounds related to #343.

[alrz]

You can already use types and arrays in attributes,

[Attr(new object[] { typeof(DateTime), 2020, 1, 1 })]

A recursive procedure of that could encode any number of nested new expressions.

[jnm2]

That would scope out static member accesses and invocations. It might still be possible to tack on object initializer syntax with an encoding like that though.

[jnm2]

If parameter default values also gained the same capabilities, but also allowed instance member access (always passing this as arg0), you get caller-receiver for free:

public Person With(string name = Name, string age = Age) => new Person(name, age);

And by 'free' I mean tons and tons of work.

[jnm2]

This would go well with discriminated unions.

[alrz]

That would scope out static member accesses and invocations

I haven't read how compiler encode types in attributes, but it should be using some kind of handle. Theoretically, if we can encode RuntimeTypeHandle, we can do the same for RuntimeMethodHandle. There is no handleof(Method) syntax, but that's how expression trees encode method groups today. So I can imagine we could do both:

[Attr(Method)]
[Attr(Method(1))]

using the same handle+array encoding above.

[Timwi]

It does seem to me that #343 would entirely cover the use-cases for this proposal plus more. The given example would be written as

public interface ICache<T> where T : class
{
    bool IsExpired { get; }
    T? Value 
    { 
        [return: NotNullWhen(c => !c.IsExpired)]
        get; 
    }
}

and

[Attr(() => Method(1))]