- Proposed
- Prototype: Not Started
- Implementation: Not Started
- Specification: Not Started
This feature intends to allow developers to apply attributes directly to the backing fields of auto-implemented properties.
Currently it is not possible to apply attributes to the backing fields of auto-implemented properties. In those cases where the developer must use a field-targetting attribute they are forced to declare the field manually and use the more verbose property syntax. Given that C# has always supported field-targetted attributes on the generated backing field for events it makes sense to extend the same functionality to their property kin.
In short, the following would be legal C# and not produce a warning:
[Serializable]
public class Foo {
[field: NonSerialized]
public string MySecret { get; set; }
}
This would result in the field-targetted attributes being applied to the compiler-generated backing field:
[Serializable]
public class Foo {
[NonSerialized]
private string MySecret_backingField;
public string MySecret {
get { return MySecret_backingField; }
set { MySecret_backingField = value; }
}
}
As mentioned, this brings parity with event syntax from C# 1.0 as the following is already legal and behaves as expected:
[Serializable]
public class Foo {
[field: NonSerialized]
public event EventHandler MyEvent;
}
There are two potential drawbacks to implementing this change:
- Attempting to apply an attribute to the field of an auto-implemented property produces a compiler warning that the attributes in that block will be ignored. If the compiler were changed to support those attributes they would be applied to the backing field on a subsequent recompilation which could alter the behavior of the program at runtime.
- The compiler does not currently validate the AttributeUsage targets of the attributes when attempting to apply them to the field of the auto-implemented property. If the compiler were changed to support field-targetted attributes and the attribute in question cannot be applied to a field the compiler would emit an error instead of a warning, breaking the build.