System.Reflection.Attribute

[I-Omnibus]

Does it make sense for the compiler to leverage record types to simplify Attribute definitions?

For example:

[AttributeUsage(AttributeTargets.Enum)]
public record Example(string SomeMetaData, string MoreMetaData);

Equivalent to:

[AttributeUsage(AttributeTargets.Enum)]
public class ExampleAttribute : Attribute {
	public virtual string SomeMetaData { get; set; }
	public virtual string MoreMetaData { get; set; }
}

[Example(SomeMetaData = "…", MoreMetaData = "…")]
enum Sample {}

[Joe4evr]

The only thing stopping you right now is that records can't inherit from non-record types (aside from object), but it's not like that restriction can't be lifted later.

But what exactly do you believe it buys you to define an attribute type like a record? This smells very much like an XY Problem.

[jnm2]

Lifting that restriction is listed in #4144.

I'm pretty sure the goal here is simply to type fewer characters to define the attribute. It makes sense to me if you want a constructor that assigns to init-only properties. If you want settable properties, as in the final syntax @I-Omnibus shows, you have to declare properties manually. At that point, record is more characters than class rather than fewer.

[spydacarnage]

It sounds to me like what you're after is the simplicity of declaring a user-defined attribute using primary constructor syntax, not necessarily a record.

[I-Omnibus]

Kind of, but restricting it to record seems like a natural match with Attribute parameters because it automatically generates a class under the hood with the required property accessors built-in, all in a one-liner.
The compiler could easily sweeten it up with a bit of reflection (losing the "Attribute" class name suffix at the same time which seems to serve no purpose).

[amis92]

Attribute suffix is not required - it's a convention, same as name casing, or I prefix on interface names. It's just a convention with an additional compiler support for not requiring the suffix when applying the attribute.