Proposal: Introduce meta modifier to append attribute data for source generators

[X39]

1. Summary

Currently, source generators cannot declare attributes on methods to achieve functionality similar to #nullable. This limitation prevents certain scenarios from being addressed at a community level.
This proposal seeks to address this issue by enabling more complex scenarios through a new language feature.

1.1 Table of Contents

1. Summary
   1.1. Table of Contents
2. Motivation
3. Proposed syntax
4. Detail
5. Alternatives
   5.1. Allowing multiple partial declarations
   5.2. Don't change anything
6. Examples
   6.1. CheckedExceptions
   6.2. API-Controller and ProducesResponseTypeAttribute
   6.3. 6.3. Copying documentation into attributes

2. Motivation

I am currently considering creating CheckedExceptions and TypeAlias analyzers. For both of these, I realized that auto-generated attributes are essential to make them truly effective.
At present, users are required to manually create these attributes, which is far from ideal due to the significant amount of additional boilerplate it imposes. There are also other scenarios from my past work where this feature would have been highly beneficial.

Due to the immutability constraints of the context in which source generators operate, I propose introducing this new language feature to address these limitations.

3. Proposed syntax

(will try to keep this updated)

MyClass.cs

[MarkerAttribute] // Marker attribute used by the hypothetical generator public class MyClass // Normal class otherwise { private float _myF = 1.0F; public void MyMethod( int i ) { /* ... */ } // ... }

MyClass.g.cs

[MetaInformationForClass] // Attribute will be added to MyType class. public meta class MyClass // New meta keyword indicates a "meta" type extension { [MetaInformationForField] // Adds this attribute to _myF private float _myF; // Cannot contribute to type or accept assignment [MetaInformationForMethod] // Adds this attribute to MyMethod public void MyMethod( [MetaParameterInformation] int i ); // Cannot have a body // ... }

4. Detail

I propose the addition of a new meta modifier, which can be applied to all type-defining constructs (e.g., class, struct, enum, interface, etc.) to specify additional metadata. The meta modifier would follow these rules:

• A meta type cannot exist independently; it must correspond to a concrete type.
• Meta types can only add attribute data and cannot contribute other type information (e.g., fields, methods, subtypes, or generics).
• A meta type may contain sub-meta-types to support nested types.
• Every symbol in a meta type must exactly match its corresponding concrete type, except attribute information.
• A meta type cannot introduce new type information beyond attributes (e.g., fields, methods, or where clauses on generics).
• Meta types are limited to operating within the current assembly.
• No additional user action (such as marking the existing type as partial) should be required to use meta types.
• If multiple meta types apply the same attribute with AllowMultiple = false, an error is raised as if the conflict occurred in the concrete type.
• Conversely, if multiple meta types apply the same attribute with AllowMultiple = true, no error is raised, and all attributes are added.

A meta type can be conceptualized as a "partial" of its corresponding concrete type, with each meta type contributing attributes to the concrete type.

5. Alternatives

5.1. Allowing multiple partial declarations

An alternative approach could be to allow multiple partial declarations to coexist. Currently, this is not permitted because the compiler raises a Member with the same signature is already declared error.

However, this approach has several downsides:

• It would require partial methods to be allowed without a corresponding implementation, as a source generator might not always decide to add attributes.
• Every type or member that a source generator might extend would need to be explicitly marked as partial, which adds additional overhead and complexity for users.

5.2. Don't change anything

Not changing anything, obviously, has the benefit of no changes being required. The user will have the burden of adding attributes to the correct place and source generators will continue to have limited attributation capabilities.

6. Examples

The following sub-chapters provide examples that have been simplified as much as possible. Please focus on the concepts being illustrated rather than critiquing the code itself, and consider the examples as presented for clarity.

6.1. CheckedExceptions

Consider the following, very simple example:

MyClass.cs

[GenerateThrows] public class MyClass { public void MyMethod() { if (!SelfCondition()) throw new MyException(); } private bool SelfCondition() { try { var fileContents = System.IO.File.ReadAllText("MyFile.txt"); return fileContents == "true"; } catch (ArgumentException) { throw; } catch (PathTooLongException) { throw; } catch (DirectoryNotFoundException) { throw; } catch (IOException) { throw; } catch (UnauthorizedAccessException) { throw; } catch (FileNotFoundException) { throw; } catch (NotSupportedException) { throw; } catch (SecurityException) { throw; } } }

MyClass.g.cs

public meta class MyClass { [Throwing<MyException>()] [Throwing<ArgumentException>()] [Throwing<PathTooLongException>()] [Throwing<DirectoryNotFoundException>()] [Throwing<IOException>()] [Throwing<UnauthorizedAccessException>()] [Throwing<FileNotFoundException>()] [Throwing<NotSupportedException>()] [Throwing<SecurityException>()] public void MyMethod(); [Throwing<ArgumentException>()] [Throwing<PathTooLongException>()] [Throwing<DirectoryNotFoundException>()] [Throwing<IOException>()] [Throwing<UnauthorizedAccessException>()] [Throwing<FileNotFoundException>()] [Throwing<NotSupportedException>()] [Throwing<SecurityException>()] public bool SelfCondition(); }

The sheer amount of boilerplate required quickly becomes overwhelming and difficult to manage in source code. Expecting users to manually add all of this is not only tedious but also makes the code harder to read and maintain.

Meta types significantly reduce this burden by enabling the source generator to handle the heavy lifting automatically. Users are freed from the complexity, needing only to add the marker attribute to leverage this functionality effortlessly.

6.2. API-Controller and ProducesResponseTypeAttribute

Consider the following, very simple example:

MyApiController.cs

[ApiController] [Route(Constants.Routes.Events)] [GenerateApiAttributes] public class MyApiController( IMyUserDataService UserDataService, IMyRepository Repository ) : ControllerBase { [Authorize] [HttpGet] public async Task<ActionResult> GetEventsAsync( [FromQuery] int skip, [FromQuery] int take ) { if (take <= 0) return BadRequest(); if (UserDataAservice.TryGetUserData(User, out var myUserData)) return Unauthorized(); var results = await Repository.GetData(myUserData); if (results.Count == 0) return NoContent(); return results; } }

MyApiController.g.cs

public meta class MyApiController : ControllerBase { [ProducesResponseType(typeof(void), StatusCodes.Status400BadRequest)] [ProducesResponseType(typeof(void), StatusCodes.Status401Unauthorized)] [ProducesResponseType(typeof(void), StatusCodes.Status204NoContent)] [ProducesResponseType(typeof(IEnumerable<Event>), StatusCodes.Status200OK)] public async Task<ActionResult<IEnumerable<Event>>> GetEventsAsync( int skip, int take ); }

The meta class facilitates automated type annotation for API controllers, significantly reducing the likelihood of human errors when annotating data that code depends on.

For instance, ProducesResponseType attributes can be automatically generated, ensuring that accurate and consistent OpenAPI documentation is produced in all cases. This process is seamlessly supported by a source generator in this scenario, streamlining the development workflow.

6.3. Copying documentation into attributes

In some cases, it is necessary to extract documentation comments and embed them into attributes for later use via reflection.

This proposed language feature would enable source generators to accomplish this efficiently, streamlining the process and reducing manual effort.

SomeCommandThing.cs

public abstract class SomeCommandThing<TArg1, TArg2> { public abstract void Execute(TArg1 arg1, TArg2 arg2); }

XmlDocSummary.cs

[AttributeUsage(AttributeTargets.Method)] public class XmlDocSummary(string summary) : Attribute;

XmlDocParam.cs

[AttributeUsage(AttributeTargets.Method)] public class XmlDocParam(int index, string parameter, string text) : Attribute;

MyCallbackHandler.cs

public class MyCallbackHandler : SomeCommandThing<int, string> { /// <summary> /// Some Text /// </summary> /// <param name="arg1">Text of Arg1</param> /// <param name="arg2">Text of Arg2</param> public override void Execute(int arg1, string arg2) { // ... } }

MyCallbackHandler.g.cs

public meta class MyCallbackHandler { [XmlDocSummary("Some Text")] [XmlDocParam(0, "Arg1", "Text of Arg1")] [XmlDocParam(1, "Arg2", "Text of Arg2")] public void Execute(int arg1, string arg2); }