C# 7.x: Allow field-targeted attributes on auto-property declarations

[RexJaeschke]

Note that v6 PR #11 modifies much of 15.7.4, and in this new PR, we’re adding new text at the end of that section, which should not overlap with the v6 mods, which had not yet been merged when this new PR was created.

[BillWagner]

converting to draft: C# 7.x feature

[jskeet]

I'll fix up the example - possibly replacing the attribute with a different one, to avoid any interpretation that this feature is linked to serialization.

[jskeet]

Okay, having changed the attribute in question, I'm personally happy with this - if others are happy, we can merge it tomorrow.

[KalleOlaviNiemitalo]

This needs changes in §21.3 Attribute specification as well.

Change to allow field on auto properties:

csharpstandard/standard/attributes.md

Line 278 in a14d97c

- `field` — a field. A field-like event (i.e., one without accessors) can also have an attribute with this target.

Change to list field and property as valid targets on auto property, and specify that property is the default:

csharpstandard/standard/attributes.md

Line 286 in a14d97c

Certain contexts permit the specification of an attribute on more than one target. A program can explicitly specify the target by including an *attribute_target_specifier*. Without an *attribute_target_specifier* a default is applied, but an *attribute_target_specifier* can be used to affirm or override the default. The contexts are resolved as follows:

[jskeet]

This needs changes in §21.3 Attribute specification as well.

Done in another commit. I've currently kept the singular form in the first part of the description, for consistency with the rest, but I'm tempted to change it to "Field-like events and automatically implemented properties can ..."

[KalleOlaviNiemitalo]

Shall the compiler issue a warning here?

using System;
class C {
    C() { P = 1; }

    [field: Obsolete]
    int P { get; }
}

csharpstandard/standard/classes.md

Line 3381 in ab777da

When a property is specified as an automatically implemented property, a hidden backing field is automatically available for the property, and the accessors are implemented to read from and write to that backing field. The hidden backing field is inaccessible, it can be read and written only through the automatically implemented property accessors, even within the containing type. If the auto-property has no set accessor, the backing field is considered `readonly` ([§14.5.3](classes.md#1453-readonly-fields)). Just like a `readonly` field, a read-only auto-property may also be assigned to in the body of a constructor of the enclosing class. Such an assignment assigns directly to the read-only backing field of the property.

csharpstandard/standard/attributes.md

Line 770 in ab777da

If a program uses a type or member that is decorated with the `Obsolete` attribute, the compiler shall issue a warning or an error. Specifically, the compiler shall issue a warning if no error parameter is provided, or if the error parameter is provided and has the value `false`. The compiler shall issue an error if the error parameter is specified and has the value `true`.

[KalleOlaviNiemitalo]

Could perhaps add to §14.7.4

Such an assignment assigns directly to the read-only backing field of the property. If the backing field is decorated with the Obsolete attribute (§21.5.4), that shall not cause the compiler to issue a warning or an error about the assignment.

or to §21.5.4

If a program uses a type or member that is decorated with the Obsolete attribute, the compiler shall issue a warning or an error, unless the member is the backing field of an automatically implemented property (§14.7.4).

[jskeet]

I'm not sure that's necessary, as I'd personally argue that the property (which is the member being used) effectively isn't decorated with the Obsolete attribute. However, the technical group can discuss that in our meeting in a few hours.

[jskeet]

Whoops - I understand your point now, about that specific case referring to the field.
The same is true for field-like events.

Given the latter part, the group has decided that we'll merge this PR, and raise a new issue about it to fix for both. (The reverse case is interesting too, where the property is obsolete but the field isn't.) Intuition from Mads: the code effectively refers to the property, and the fact that it refers to a field is "sort of" an implementation detail - so it may be that we tweak 14.7.4 a little. But we'll deal with it in the new issue (which I'll link to this one).

[gafter]

🐸

[jskeet]

@KalleOlaviNiemitalo: On a separate note, thank you for everything you've been spotting in this PR and others. We really appreciate it.