[BillWagner]

This PR contains the work for init accessors in C# 9.

The commits from #978 were squashed to one commit in this branch.

There are a number of comments that haven't been addressed on #978:

• https://github.com/dotnet/csharpstandard/pull/978/files#r2326611994
• https://github.com/dotnet/csharpstandard/pull/978/files#r1378416566
• https://github.com/dotnet/csharpstandard/pull/978/files#r2326613914

Notes:

• The ANTLR grammar validation fails for one test where the validation is designed to fail – it is testing that right shift is not erroneously recognised – and the checker passes the test if the error message is what it expected. Antlr writes a long informative error message listing all the tokens it might have expected to find at the failing point of the code and that list now has init in it.
• The renumbering action fails because this feature depends on the grammar in "records".

[RexJaeschke]

Should "containing class or struct" be extended to include interface? Here and a few other table rows below?

[BillWagner]

An earlier version of this feature is already present on alpha-v9 from a prior meeting. Edits made to this PR since then are not yet on alpha-v9; they will land at the next propagation. If you need them on alpha-v9 sooner, please open a separate PR targeting alpha-v9.
Thanks!

[jskeet]

Applied "meeting: discuss" so that we can all perform a first round of review before the next meeting.

[Nigel-Ecma]

This is a partial review, stopped after reviewing classes.md.

I think changes are required.

[Nigel-Ecma]

I think this is description of a certain implementation, there appears to be no language level reason to require this. (Also there seems to be no CLR reason to do this; the CLR allows extra methods [accessors in C#] in a property. It is a particular C# implementation’s choice.)

It is also counter to the C# description of signature, which includes the name.

The language restriction is that there cannot be both a set and an init accessor.

Recommendation: remove

Suggested change

	A set accessor and init accessor have the same signature; however, that for the init accessor also has an implementation-defined form of annotation to distinguish it from a set accessor.

[jskeet]

We could possibly add a note that init_P is not reserved. (But it doesn't need to be normative text.)

[jskeet]

We think this is okay - it's about the method signatures rather than the property accessor names being reserved.

[Nigel-Ecma]

See comment for properties

[Nigel-Ecma]

See comment for properties

[Nigel-Ecma]

Missing word? Also an -> a

Suggested change

	For a ref-valued property the *ref_get_accessor_declaration* consists optional attributes, an optional *accessor_modifier*, the token `get`, followed by an *ref_accessor_body*.
	For a ref-valued property the *ref_get_accessor_declaration* consists of optional attributes, an optional *accessor_modifier*, the token `get`, followed by a *ref_accessor_body*.

[Nigel-Ecma]

What is this “instance”, it seems to pop up out of nowhere. Just sketching, hence not a suggestion block…

At the point a property’s init accessor is invoked, the property’s containing/owning type instance is known to be in the construction phase. Hence an init accessor may take the following actions in addition to what a set accessor can do:

1. Set the value of read-init/init-only properties accessible through this or base
2. Assign readonly fields declared on the same type through this

This also changes the wording “Call other init accessors” as code doesn’t directly call an accessor, unlike methods are directly called – the accessor is invoked as the consequence of some other action (assignment, ++, etc.). This might be a wider issue though!

[jskeet]

Line 3781 isn't too much earlier, although it refers to "object" instead of "instance":

An instance property containing an init_accessor_declaration is considered settable during the construction phase of the object

But I don't object to us making it clearer, of course.

[Nigel-Ecma]

Intentionally 2 errors (assignment & spelling) or not? If intentional it is fine.

[jskeet]

My guess is that it's intentionally different but we might want to have a better example.

[Nigel-Ecma]

Following the spirit of the suggestion on 3494, why not:

Suggested change

	- A set accessor corresponds to a method with a single value parameter of the property type, a void return type, and the same modifiers as the containing property.
	- An init accessor corresponds to a method with a single value parameter of the property type, a `void` return type, and the same modifiers as the containing property.
	- A set or init accessor corresponds to a method with a single value parameter of the property type, a `void` return type, and the same modifiers as the containing property.

I tending to think that init & set accessors should be described as differing only in when they can be invoked, and not be listing out the (identical) other features.

[Nigel-Ecma]

Is it stated elsewhere that all overrides for set & get also need to be “marked” set & get respectively?

I’m unsure whether the second sentence is saying something useful, or is maybe coming from a particular implementation translating an init into a set with flag. If it is the latter then an earlier suggestion has been made to remove this implementation specific detail, and if that is accepted then the text here might need to be reworded as well. (I.e. if the Standard never surfaces the implementation specific detail that an init is a set why would anyone think you can override one with the other?)

[jskeet]

We think this is okay - it's about the method signatures rather than the property accessor names being reserved.

[jskeet]

Reading this change again, "however, that for the init accessor" reads very oddly to me.

[Nigel-Ecma]

@jskeet – It is odd & implementation specific, I recommended deleting it above

[jskeet]

I hadn't spotted before that we have these definitions. I wonder whether we should keep them and refer to them, but introduce a new term of "it's only got a get access but it's wriable-ref-returning, so you can still use it as the target of an assignment". (This has come up in a few places recently.)

[jskeet]

Suggested change

	> var p = new Point() { X = 42, Y = 13 };
	> var p = new Point { X = 42, Y = 13 };

(Just to be more idiomatic.)

[jskeet]

I don't understand the "except when in a local function or lambda" part. When what is in a local function or lambda? Presumably the code that is invoking the init-accessor? An example might be beneficial.

[Nigel-Ecma]

@jskeet – The restriction is (at least) that you cannot define a lambda in a constructor the body of which attempts to init the property. E.g.:

    internal class Program
    {
        static void Main(string[] args) { new Program(); }

        public Program()
        {
            P = 36; // OK
            (Func<int, int>)(x => Q = x) = 42; // Err: Init-only Q can only be assigned in an initializer
        }

        private int p;
        int P
        {
            get { return p; }
            init { p = value; }
        }

        private int q;
        int Q
        {
            get { return q; }
            init { q = value; }
        }
    }

Agree a (better than the above) sample would be helpful.

[jskeet]

Right. I think an example and a rewording would be helpful. Something about "can't be set via an implicit or explicit this reference captured by an anonymous function".

[jskeet]

Does that include casting this to a derived type within a base type constructor?

internal class Base
{
    public Base()
    {
        // This isn't valid...
        if (this is Derived d)
        {
            d.X = 10;
        }
        // And neither is this...
        (Derived) this.X = 10;
    }
}

internal class Derived
{
    public int X { get; init; }

    public Derived()
    {
        X = 10;
    }
}

Maybe only refer to base types?