Constant array initialization in attribute is inconsistent

[hughbe]

The following code fails to compile with

Compilation error (line 11, col 15): An attribute argument must be a constant expression, typeof expression or array creation expression of an attribute parameter type

Replacing new int[1] with new int[] { 0 }, which is identical, works.

I suggest that both should compile, rather than just new int[] { 0 }

using System;

public class MyAttribute : Attribute
{
	public MyAttribute(object value) { }
}

public class Program
{	
	[MyAttribute(new int[1])]
	public void DoesNotCompile() {}
	
	[MyAttribute(new int[] { 0 } )]
	public void DoesCompile() {}

	public static void Main()
	{		
		Console.WriteLine("Hello World");
	}
}

[BraedonWooding]

new int[] { 0 } is not a compile time constant that's the problem, since you have to create the array then initialize it with values, just like calling something like;

var myArray = new int[1];
myArray[1] = 0;
// EQUAL TO
var myArray = new int[] { 0 };

Similar reason why you can't use classes due to the constructor. The only allowed types are;

• Simple types (bool, byte, char, short, int, long, float, and double)
  string
• System.Type
• enums
• object (The argument to an attribute parameter of type object must be a constant value of one of the above types.)
• One-dimensional arrays of any of the above types (same constraint as object; i.e. constant value).

[yaakov-h]

@BraedonWooding I think you have this backwards...

Also you've said "The only allowed types are... one-dimensional arrays of any of the above types" where "the above types" includes "int".

new int[1] is a one-dimensional array of type int.

[BraedonWooding]

Yes but new int[] { 0 } isn't a constant value... which is what I was meaning. That int[] is but the initializer makes it non-constant.

[yaakov-h]

Like I said, I think you have it backwards.

new int[] { 0 } works today in Visual Studio and C# Interactive. Roslyn considers it a constant value. That's not what this issue is about.

It's new int[1] that doesn't work.

[HaloFour]

Personally I prefer that the C# compiler forces you to supply the constant values for each element in the array, even if those values would be the default values. As an imposed limitation there must have been an explicit design choice that went into the requirement of supplying those values.

[BraedonWooding]

Ahhhh I see don't mind me being stupid a little :P.

[hughbe]

@HaloFour obviously for new int[1], this is unecessary. I don't know how common this use case is, but I'm validating things like new byte[33], new byte[31] in unit tests etc. Other similar cases include anything that is really greater than the how many zeroes new byte[] { 0, 0, ...} you can fit on the screen.

[HaloFour]

@hughbe

I don't know how common this use case is, but I'm validating things like new byte[33], new byte[31] in unit tests etc.

You're writing that validation in attributes?

[hughbe]

@HaloFour for example xunit uses attributes to pass test data to test methods. I've been writing tests for crypto and system.drawing over in corefx. These libraries use the pattern of passing an array as a parameter to a method or value to a property and validating the length, so I have encountered this design decision many many times.

[HaloFour]

@hughbe

I see. I don't particularly care either way but I'm loathe to push for language changes specifically to suit the behaviors of a specific third-party library/framework. Data-driven tests in xunit appear to have a fairly pluggable method of providing test data so you're not strictly limited to trying to stuff giant byte arrays directly into an attribute (especially where I'm sure those arrays are likely to contain something other than all zeroes anyway). For example (and I'm not necessarily suggesting this as a solution to your problem), you could extend DataAttribute and have it accept an array of embedded resource names then have the attribute actually read those resources and return them as an enumerable of byte arrays.

[hughbe]

I don't particularly care either way but I'm loathe to push for language changes specifically to suit the behaviors of a specific third-party library/framework.

Thanks for the reply and suggestion!

That's why I was hesitant to bring the xunit part up in the first place, I was afraid it would limit the discussion of what I see as an inconsistency in the language to specific use cases.