[Version 9.0] Feature support for `init` accessors by BillWagner · Pull Request #1452 · dotnet/csharpstandard

BillWagner · 2025-11-06T18:46:03Z

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:

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 · 2025-11-07T13:56:37Z

 >     <td rowspan="6">Property access</td>
 >     <td><code>P</code></td>
->     <td>The get accessor of the property <code>P</code> in the containing class or struct is invoked. A compile-time error occurs if <code>P</code> is write-only. If <code>P</code> is not <code>static</code>, the instance expression is <code>this</code>.</td>
+>     <td>The get accessor of the property <code>P</code> in the containing class or struct is invoked. A compile-time error occurs if <code>P</code> is write-only or init-only. If <code>P</code> is not <code>static</code>, the instance expression is <code>this</code>.</td>


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

BillWagner · 2026-06-24T18:33:45Z

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 · 2026-07-22T20:15:10Z

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

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Nigel-Ecma

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

I think changes are required.

Nigel-Ecma · 2026-09-07T06:02:31Z

+
+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.


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.

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

jskeet · 2026-09-09T20:53:08Z

 ```

-Both signatures are reserved, even if the property is read-only or write-only.
+Both signatures are reserved, even if the property has only one accessor.


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

Nigel-Ecma · 2026-09-07T06:16:10Z

 ```

-Both signatures are reserved, even if the indexer is read-only or write-only.
+Both signatures are reserved, even if the indexer has only one accessor.


See comment for properties

Nigel-Ecma · 2026-09-07T06:16:20Z

-Both signatures are reserved, even if the indexer is read-only or write-only.
+Both signatures are reserved, even if the indexer has only one accessor.
+
+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.


See comment for properties

Nigel-Ecma · 2026-09-07T06:18:56Z

-The *accessor_declarations* consist of a *get_accessor_declaration*, a *set_accessor_declaration*, or both. Each accessor declaration consists of optional attributes, an optional *accessor_modifier*, the token `get` or `set`, followed by an *accessor_body*.
+The *accessor_declarations* consist of either a *get_accessor_declaration*, optionally with a *set_accessor_declaration* or an *init_accessor_declaration*, or a *set_accessor_declaration* or *init_accessor_declaration* optionally with a *get_accessor_declaration*.  Each accessor declaration consists of optional *attributes*, an optional *accessor_modifier*, the token `get`, `init`, or `set`, followed by an *accessor_body*.

 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*.


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 · 2026-09-07T23:11:01Z

+At the point an init accessor is invoked, the 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. Call other init accessors available through `this` or `base`
+1. Assign `readonly` fields declared on the same type through `this`


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:

Set the value of read-init/init-only properties accessible through this or base

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!

Nigel-Ecma · 2026-09-07T23:15:42Z

+        {
+            Name = "Jared"
+        };
+        local.Name = "Jraed"; // Error


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

Nigel-Ecma · 2026-09-07T23:18:14Z

 Abstract property declarations are only permitted in abstract classes ([§15.2.2.2](classes.md#15222-abstract-classes)) and interfaces ([§19.4.4](interfaces.md#1944-interface-properties)). The accessors of an inherited virtual property can be overridden in a derived class by including a property declaration that specifies an `override` directive. This is known as an ***overriding property declaration***. An overriding property declaration does not declare a new property. Instead, it simply specializes the implementations of the accessors of an existing virtual property.

-The override declaration and the overridden base property are required to have the same declared accessibility. In other words, an override declaration shall not change the accessibility of the base property. However, if the overridden base property is protected internal and it is declared in a different assembly than the assembly containing the override declaration then the override declaration’s declared accessibility shall be protected. If the inherited property has only a single accessor (i.e., if the inherited property is read-only or write-only), the overriding property shall include only that accessor. If the inherited property includes both accessors (i.e., if the inherited property is read-write), the overriding property can include either a single accessor or both accessors. There shall be an identity conversion between the type of the overriding and the inherited property.
+The override declaration and the overridden base property are required to have the same declared accessibility. In other words, an override declaration shall not change the accessibility of the base property. However, if the overridden base property is protected internal and it is declared in a different assembly than the assembly containing the override declaration then the override declaration’s declared accessibility shall be protected. If the inherited property has only a single accessor (i.e., if the inherited property is read-only, ninit-only, or write-only), the overriding property shall include only that accessor. If the inherited property includes two accessors (i.e., if the inherited property is read-write or read-init), the overriding property can include either a single accessor or both accessors. There shall be an identity conversion between the type of the overriding and the inherited property.


ninit-only typo:

Suggested change

The override declaration and the overridden base property are required to have the same declared accessibility. In other words, an override declaration shall not change the accessibility of the base property. However, if the overridden base property is protected internal and it is declared in a different assembly than the assembly containing the override declaration then the override declaration’s declared accessibility shall be protected. If the inherited property has only a single accessor (i.e., if the inherited property is read-only, ninit-only, or write-only), the overriding property shall include only that accessor. If the inherited property includes two accessors (i.e., if the inherited property is read-write or read-init), the overriding property can include either a single accessor or both accessors. There shall be an identity conversion between the type of the overriding and the inherited property.

The override declaration and the overridden base property are required to have the same declared accessibility. In other words, an override declaration shall not change the accessibility of the base property. However, if the overridden base property is protected internal and it is declared in a different assembly than the assembly containing the override declaration then the override declaration’s declared accessibility shall be protected. If the inherited property has only a single accessor (i.e., if the inherited property is read-only, init-only, or write-only), the overriding property shall include only that accessor. If the inherited property includes two accessors (i.e., if the inherited property is read-write or read-init), the overriding property can include either a single accessor or both accessors. There shall be an identity conversion between the type of the overriding and the inherited property.

Nigel-Ecma · 2026-09-07T23:21:18Z

 - 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.


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 · 2026-09-07T23:30:21Z

 >
 > *end example*

+When an init accessor appears in a virtual property, all overrides for it shall also be marked `init`. Likewise, it is not possible to override a set accessor with an init accessor.


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 · 2026-09-09T20:53:08Z

 ```

-Both signatures are reserved, even if the property is read-only or write-only.
+Both signatures are reserved, even if the property has only one accessor.


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

Add support for init accessors Add support for init accessors Add support for init accessors Add support for init accessors Add support for init accessors Add support for init accessors Add support for init accessors fix md formatting fix formatting, add xref links add xref links

Use different reasonable placeholders.

I made these tweaks after comparing the edits I researched 2+ years ago and what I found in this new feature branch.

BillWagner mentioned this pull request Nov 6, 2025

Add support for init accessors #978

Closed

RexJaeschke reviewed Nov 6, 2025

View reviewed changes

Comment thread standard/basic-concepts.md Outdated

RexJaeschke reviewed Nov 6, 2025

View reviewed changes

Comment thread standard/attributes.md Outdated

RexJaeschke reviewed Nov 6, 2025

View reviewed changes

Comment thread standard/attributes.md Outdated

RexJaeschke reviewed Nov 7, 2025

View reviewed changes

Comment thread standard/classes.md Outdated

RexJaeschke reviewed Nov 7, 2025

View reviewed changes

Comment thread standard/classes.md Outdated

RexJaeschke added the Review: pending Proposal is available for review label Nov 7, 2025

RexJaeschke added this to the C# 9.0 milestone Nov 7, 2025

BillWagner changed the title ~~Feature support for init accessors~~ [Version 9.0] Feature support for init accessors Nov 7, 2025

RexJaeschke added the type: feature This issue describes a new feature label Nov 11, 2025

jskeet self-assigned this Nov 27, 2025

BillWagner force-pushed the v9-init-accessors branch from 06286d1 to 1dd0bbe Compare April 10, 2026 16:02

BillWagner added a commit that referenced this pull request Apr 10, 2026

Apply delta from PR #1452 (Init Accessors) - 3 new review commits

ca3742e

BillWagner force-pushed the v9-init-accessors branch from 1dd0bbe to 0a30078 Compare May 12, 2026 19:27

BillWagner force-pushed the v9-init-accessors branch from d16c29a to 87260cd Compare June 24, 2026 18:15

jskeet added the meeting: discuss This issue should be discussed at the next TC49-TG2 meeting label Jul 22, 2026

BillWagner added a commit that referenced this pull request Jul 24, 2026

alpha-v9 rebuild: fixup #1452 typo ninit-only -> init-only (classes.md)

c063a64

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

BillWagner force-pushed the v9-init-accessors branch from 87260cd to 25b0a75 Compare July 24, 2026 19:51

Nigel-Ecma requested changes Sep 7, 2026

View reviewed changes

jskeet reviewed Sep 9, 2026

View reviewed changes

RexJaeschke and others added 5 commits September 18, 2026 15:55

fix word converter issues

684a621

Use different reasonable placeholders.

Update classes.md

51ac240

Apply suggestions from code review

391be46

I made these tweaks after comparing the edits I researched 2+ years ago and what I found in this new feature branch.

remove link

fb19a35

BillWagner force-pushed the v9-init-accessors branch from 25b0a75 to fb19a35 Compare September 18, 2026 19:56


		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.

	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.

		- 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 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.

Conversation

BillWagner commented Nov 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

RexJaeschke Nov 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

BillWagner commented Jun 24, 2026

Uh oh!

jskeet commented Jul 22, 2026

Uh oh!

Nigel-Ecma left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

BillWagner commented Nov 6, 2025 •

edited

Loading

RexJaeschke Nov 7, 2025 •

edited

Loading