[Proposal] Declare attributes with a shorthand keyword

[simo026q]

Attribute keyword

• Proposed
• Prototype: Not Started
• Implementation: Not Started
• Specification: Not Started

Summary

This proposal suggests introducing a new syntax for defining attributes using a dedicated keyword instead of inheriting from the System.Attribute class and appending the Attribute suffix.

Motivation

The motivation behind introducing a new attribute syntax is to enhance code expressiveness and developer experience. The current convention, requiring the inheritance of System.Attribute and appending the Attribute suffix, can lead to verbose and somewhat boilerplate code. It can also cause confusion then the suffix is automatically removed when used, resulting in a discrepancy between declaration and utilization that can be counterintuitive, particularly for those unfamiliar with this convention. Introducing a dedicated keyword for attribute declaration aims to alleviate this confusion. By introducing a dedicated, it can streamline this process, providing a more concise and readable syntax.

This change is not intended to replace the existing approach but rather as a more readable shorthand.

Detailed design

Current syntax

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, AllowMultiple = true)]
public class JsonIgnoreAttribute : Attribute
{
}

Proposal

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, AllowMultiple = true)]
public attribute JsonIgnore
{
}

Alternative proposal

public attribute multiple JsonIgnore
    where target : class, method
{
}

Drawbacks

While the proposed syntax aims to enhance code readability, there are potential drawbacks to consider.

1. Learning Curve for Existing Developers: The introduction of a new attribute declaration syntax may pose a learning curve for developers already familiar with the traditional approach. Adapting to the new syntax might initially disrupt established coding habits and workflows.

2. Compatibility and Migration: Existing codebases heavily reliant on the current attribute syntax may face challenges during the transition. Ensuring backward compatibility and providing clear migration paths (like refactorings) would be crucial to minimizing disruptions.

3. Ecosystem Consistency: If widely adopted, the new syntax could lead to a mix of codebases using both the traditional and the proposed syntax. This inconsistency across the development ecosystem might create confusion and complicate collaboration.

4. Tooling Support: IDEs, analyzers, and other development tools will need updates to fully support the proposed syntax. The lack of immediate comprehensive tooling support could impede developers' ability to take full advantage of the new syntax.

Unresolved questions

• How would it work with inherited attributes?

The exact details of the syntax and potential corner cases need further exploration and may be refined during the prototyping phase.

[siegfriedpammer]

Adding this to the language doesn't enable anything that's impossible today. Attributes are used far more than they are defined. Simplifying the definition of attributes by adding something to the language will never pay for itself. See also minus 100 points: https://learn.microsoft.com/en-us/archive/blogs/ericgu/minus-100-points

[orthoxerox]

@simo026q I use var in every method body. I use autoprops in every other class, I use primary constructors in every other class. I've written less than ten attribute declarations since 2002.

[simo026q]

My point is that some of the most useful features added are features that "doesn't enable anything that's impossible today". I'm not saying this will be anything as useful as those examples I listed.

You might not use attributes and that's fine, I've written a lot of them just this year. Just because it's not useful to you doesn't mean it can't be to others.

[simo026q]

If you could elaborate on particular drawbacks or share your perspective on how the proposal might impact existing workflows negatively, I'd gladly hear it :)

[siegfriedpammer]

and var doesn't add anything new.

@simo026q without var you could not declare variables that refer to anonymous types:

var x = new { Prop = 42 };

so no, even var adds something new... ;-)

share your perspective on how the proposal might impact existing workflows negatively

I am not suggesting that your proposal might have negative impact on workflows. I am just re-stating the often stated "minus 100 points" rule employed by many (if not all) members of the C# language design team at MS.

The only negative impact I could think of is that it would block time and people, who could work on other features instead. Every language feature takes a lot of effort to properly specify, implement and test in various areas: the compiler itself, the IDE and possibly the runtime and/or the debugger. Also, tooling authors will have to update their tools to support this feature. Last, but not least, every C# developer will have to learn about this new feature (at some point) so they can read/understand the code written by somebody else, even if they do not use the new features themselves. Which is probably the biggest problem, we have to consider, when adding new features. It all adds complexity and cognitive load.

Note, I am not trying to gate-keep or anything, I am just giving my perspective as C# developer and C# tools developer, who has to think a lot about any new language feature added by the C# designers.

[simo026q]

This comment is much more useful, and I can certainly respect your point of view. I'll rewrite the proposal to give a bit more context.

[iam3yal]

It would have been awesome if you could do something like this through SG:

[AttributeGenerator(AttributeTargets.Class | AttributeTargets.Method, AllowMultiple = true)]
public class JsonIgnore
{
}

It's possible to do today but then you would have two types as opposed to a single one.

[simo026q]

I don't think SG would help make it less complicated, especially for people learning.

[HaloFour]

I agree that it's a question of ROI. Maybe a shorter syntax would be nicer here, but the vast majority of developers never write their own attributes so there is extremely little to gain. Attributes have existed in C# since the beginning and defining them has never been considered a pain point.

Notable, the use of attributes in cases like this was done intentionally to avoid having to add new syntax to support every feature.