Does source generated code means losing on refactoring?

[fullstackduck]

Brief description:

For reference let's take INotifyPropertyChanged example of source generation from the source generators cookbook.

While it's amazing to have that boilerplate code generated.
However, losing the ability to refactor makes it feel like 1 step forward 2 steps backward.

If it takes off, I see my projects as heavily dependent on generated code but not able to refactor say the property Count to NewCount is a dealbreaker.
I would not want to rename a few of these properties manually in hundreds of places.

Additional information:

It's not much of a suggestion but a query on what are the expectations regarding this.

[jmarolf]

@parveenkhtkr this is a good point that using strings for the names of properties is a take-back. Currently refactoring's such as Rename are not able to see and rename generated code right @jasonmalinowski?

CC: @chsienki, @CyrusNajmabadi

[sharwell]

Refactorings should be able to see generated code, but that code is not able to be changed (directly) by a refactoring.

[sharwell]

If a particular refactoring scenario is important with respect to some body of generated code, the author of the relevant source generator would be expected to design the source generator inputs and outputs such that it retained support for that scenario. The example linked above does not retain support for the Rename refactoring for generated properties, but it is also not the only way to implement a source generator for INotifyPropertyChanged. In theory, a different design and implementation for an INotifyPropertyChanged source generator would be able to work seamlessly with the Rename refactoring.

[jmarolf]

Renaming the field would change the name of the property that is generated, breaking all the callsites.

In theory, a different design and implementation for an INotifyPropertyChanged source generator would be able to work seamlessly with the Rename refactoring.

I guess without an existence proof I can't really say I agree with this.

[sharwell]

@jmarolf The absence of such a design does not invalidate my comment. In just means that one of the following is true:

1. This refactoring does not work with Rename as a known and accepted limitation
2. INotifyPropertyChanged is not a good candidate for a source generator for this user at this time

Other potential ways to implement this include:

• Define an interface for the properties instead of fields (rename might work from the interface)
• Define an abstract base class for abstract properties instead of fields (rename would work from the base class)

[jasonmalinowski]

So we've discussed in passing the concept of a generator being able to give hints to rename or other refactorings to allow things to work. In the example linked above, having an extensibility point that lets the generator say "if you're renaming this symbol, also rename that symbol"; there's plenty of places such a thing would be useful. We haven't done any careful design on that though. We're still very much in a "walk before we can run" stage of IDE experience around generators.

Also yes, right now we simply block rename if the symbol comes from generated code, since that was the easiest thing to do. We could perhaps weaken that a little bit but it offers the user a bunch of ways to shoot themselves in the foot, and we didn't want to just open that up without some thought.