`field` keyword in auto properties

[ds5678]

Feature request

dotnet/csharplang#8635

Additional context

• I think this depends on Roslyn 5.0.0 #3588.
• I'm willing to work on it.

[christophwille]

Fyi,Copilot assigned only to see what happens.

[siegfriedpammer]

It will not work because only roslyn 5 properly supports the language feature

Roslyn 4 should produce an error internally when binding the syntax tree. At least you get an InvalidOperation when trying to process ASTs with the field keyword.

[siegfriedpammer]

@ds5678 Thank you very much! Great that you are interested in working on this. I made some suggestions on the Copilot PR on how I would approach this feature and I was completely misunderstood by the AI. See #3625 (comment) for my suggestion, do you think it makes sense?

[siegfriedpammer]

The only downside with my idea that comes to mind is that it is somewhat difficult to implement support for auto-properties if the field keyword language feature is not enabled on lower language version levels.

[ds5678]

What's the expectation here?

• Semi-auto properties should use field even when the C# target version for decompilation is less than 14.
• Semi-auto properties should use a speakable name for the backing field when the C# target version for decompilation is less than 14.

[siegfriedpammer]

Good question... I think we should just keep the compiler-generated field around.

So, how would we go about transforming public int A { get; set; }?

With C# 14:

	[CompilerGenerated]
	[DebuggerBrowsable(DebuggerBrowsableState.Never)]
	private int <A>k__BackingField;

	public int A
	{
		[CompilerGenerated]
		get
		{
			return <A>k__BackingField;
		}
		[CompilerGenerated]
		set
		{
			<A>k__BackingField = value;
		}
	}

becomes

	public int A
	{
		[CompilerGenerated]
		get
		{
			return field;
		}
		[CompilerGenerated]
		set
		{
			field = value;
		}
	}

becomes

	public int A { get; set; }

but without C# 14, we might have to add a transform that "undoes" the <A>k__BackingField -> field transform if A cannot be translated to a full auto-property?

[siegfriedpammer]

A = Language feature full-auto-properties
B = Language feature semi-auto-properties

enable none:

	[CompilerGenerated]
	[DebuggerBrowsable(DebuggerBrowsableState.Never)]
	private int <A>k__BackingField;

	public int A
	{
		[CompilerGenerated]
		get
		{
			return <A>k__BackingField;
		}
		[CompilerGenerated]
		set
		{
			<A>k__BackingField = value;
		}
	}

enable both:

public int A { get; set; }

enable B:

	public int A
	{
		[CompilerGenerated]
		get
		{
			return field;
		}
		[CompilerGenerated]
		set
		{
			field = value;
		}
	}

enable A, this works today, but would require extra effort to support after my refactoring idea:

public int A { get; set; }

My reasoning behind the refactoring idea was:

• avoid having a separate code path for field
• reduce code duplication

But all the language options make this a lot harder than I initially imagined.

[siegfriedpammer]

• Semi-auto properties should use field even when the C# target version for decompilation is less than 14.

• Semi-auto properties should use a speakable name for the backing field when the C# target version for decompilation is less than 14.

Your first suggestion would be the easier solution, but it would also break the expectation that we do not transform syntactic sugar on language levels where it's not supported.

And I was going to write: Your second suggestion would be an interesting new concept we haven't done before: i.e. assign new names to entities other than local variables.

But, then I realized that we already have:

ILSpy/ICSharpCode.Decompiler/CSharp/Transforms/FixNameCollisions.cs

Lines 28 to 35 in f54955a

	/// <summary>
	/// Rename entities to solve name collisions that make the code uncompilable.
	/// </summary>
	/// <remarks>
	/// Currently, we only rename private fields that collide with property or event names.
	/// This helps especially with compiler-generated events that were not detected as a pattern.
	/// </remarks>
	public class FixNameCollisions : IAstTransform

So making the field names of the form <PropertyName>k__BackingField speakable names, wouldn't actually be that much of a new concept.

[ds5678]

making the field names of the form k__BackingField speakable names, wouldn't actually be that much of a new concept

[CompilerGenerated]
[DebuggerBrowsable(DebuggerBrowsableState.Never)]
private int _003CValidatedProperty_003Ek__BackingField;

According to my failing unit tests, this is already being done.

[ds5678]

Unless you meant something like renaming it to PropertyName__BackingField, which is more readable.