Dummy declarations for Source Generators

[silver-sd]

This proposal suggests the ability to create declarations that are accessible only by Source Generators(SG) and are not emitted into the resulting assembly.

The currently available possibility to modify an existing method by Source Generator(SG) is to declare a method with a modified name, with some suffix like underscore '_'.
SG creates the new method without this suffix in the name.

//Has the suffix '_' at the end of the name
[MySourceGenerator1] void MyMethod_()
{
    //some code that will be changed by SG
}

//...
//Method created by SG. The suffix '_' after the name was removed.
void MyMethod()
{
    //this code is based on MyMethod_ but it was changed by SG
}

It works well. But there are 2 problems:

• Old version MyMethod_ is emitted into the assembly and it becomes a dead code.
• Suffix in the name create a visual noise.

Proposal:

• The possibility to create a custom attribute which makes any declaration "dummy" when it is applied to that declaration.
  For example: this attribute is created by deriving from a special class or by marking by some attribute
• Such dummy declaration (marked by this attribute) is not emitted into the resulting assembly. And the references to it from the other code are not allowed.
• At early stages of compilation the declaration marked by such attribute is renamed by adding some suffix (or some other way).
  SG can generate declaration with the same name as the original name of the dummy declaration without naming conflicts.

This approach avoids issues related to immutability and so on. SG only appends the new code. But, in effect, it makes possible to rewrite declarations by SG.

[HaloFour]

I believe that you can use ConditionalAttribute to achieve this behavior. Combine it with ObsoleteAttribute if you want attempts to call that method to be an error (or the SG could do that itself).

[silver-sd]

ConditionalAttribute has the following limitations:

• Can be applied to methods only with 'void' return type (not properties, not fields)
• Non-empty string parameter to ConditionalAttribute is mandatory
• It is a sealed class

So it can not be used in scenarios like this:

//Source Generator will create the property MyProperty and the backing field _myProperty (or myProperty)
//The declared field MyProperty is dummy and SG can create the real declaration with the same name.

[MyDependencyPropertyGenerator]  // It is more readable if there is only one attribute derived from a proper class
int MyProperty; // It is more readable if it is a property name. It's not a backing field : _myProperty

[HaloFour]

See: #6420

[HaloFour]

I know that doesn't completely satisfy your request either. I think the general request would be to either:

1. Have a general purpose way to express a method within the source that is evaluated by the compiler to the extent that a source generator can emit companion source based on it, but which isn't emitted into the assembly itself. That is your suggestion, however I would say that using the name wouldn't be a sufficient way to handle that as MyMethod_ is a perfectly legal C# identifier.
2. Have a general purpose way for a source generator to omit a declarations from the compilation. Source generators are currently intentionally additive as it makes them much simpler: they just spit out more source, they cannot affect existing source. Allowing this would create a host of issues as the compilation up to that point is now suspect.

Assuming such a thing were to consider, I think the easiest route would be to allow ConditionalAttribute to be applied to more members.

Most of the focus seems to be around expanding support for partial, which would allow you to provide declarations where the generator provides the implementation. Not situations where the generator can consume a partial implementation, rewrite it and emit a member. The team eventually declined to implement "original/replace" as a method of general purpose AOP via source generators due to complexity and perceived confusion, so it's hard to say how they would feel about expanding support in this particular area.

[silver-sd]

Generally, since the introduction of SG it seems natural to have a possibility to pass information to SG without much syntax overhead, limitations, and without producing unused(dead) code.
This information is readonly for SG, so the additive nature of SG stays intact. It is more about ConditionalAttribute functionality (or a new similar attribute).

There are several levels of implementation complexity (from more realistic to less realistic):

[Conditional("_")] 
[MySourceGenerator] //declaration ...

If the mandatory non-empty string parameter was removed there would be less overhead:

[Conditional] //condition that will never be true
[MySourceGenerator] //declaration ...

2. If ConditionalAttribute was not sealed, MySourceGeneratorAttribute would be derived from it:

[MySourceGenerator] //declaration ...

3. Extending the valid targets to support methods with return values and classes. It is possible only if the declarations are not referenced from code.

4. Name ambiguity.
   It could be implemented internally or just by renaming at early stages of compilation (like the preprocessor): "F1_DummySuffix"

 [Conditional] //This condition will never be true 
 void F1() {} //This declaration will never be referenced and must not issue "Error: Member with the same signature is already defined"
 
 void F1() {} //Real declaration with the same name

[HaloFour]

Ultimately I think the use case is that you want to be able to define a method, with implementation, and have the source generator amend that implementation. The limitations of source generators, particularly that they are additive only, are what drive the conversation about being able to define these partial implementations which are then replaced by the real implementation. If source generators offered a way to wholesale replace a method with the generated implementation, this use case could be covered without needing any language changes.