C# 6.0 feature: collection (index) initializers, and extension add method for initializers. #8

BillWagner · 2020-10-23T20:01:03Z

It was hard to separate these two, so adding them together.

Nigel-Ecma · 2020-11-18T15:36:09Z

standard/expressions.md

 > ```
 > *end example*

+> *Example*: Given an appropriate definition of `C`, the following example:


The "appropriate definition" here presumably includes:

either an init which creates an empty array for z, and object for y, etc.

or the generated new calls are not shown in the equivalent series of assignments

Does this need to be made clearer, corrected, or am I missing something?

No, I don't think that's required for the example - the example will throw an exception if executed and the initializer doesn't create an empty array for z etc, but when the point is to say "It's equivalent to this code" I don't think we need to care about what happens at execution time beyond the translation.

Given that this is only informative, I think it's reasonable not to specify what "appropriate" means.

I do wonder whether we should use X, Y and Z as more idiomatic names though.

What I'm not sure is clear is (taking from the example below) when it is valid/required to write:

phoneNumbers = { "206-555-0101", "425-882-8080" };

vs.

phoneNumbers = new List<string> { "206-555-0101", "425-882-8080" };

for the cases when phoneNumbers is a local/global variable, field of an object, etc.

Re: x vs. X: are these not field names which conventionally start with lowercase? See the next example with phoneNumbers and PhoneNumbers.

Most code conventions require fields to be private, which means this would only be valid inside the code for C. I very, very rarely see object initializers used to initialize fields - they're almost always used with properties in my experience. While it isn't "wrong" to show fields, I think it would be more helpful to show the more common usage.

(Will discuss the other part in the meeting... out of time now :)

standard/expressions.md

jskeet · 2020-11-18T20:31:33Z

standard/expressions.md

 ```

-An object initializer consists of a sequence of member initializers, enclosed by `{` and `}` tokens and separated by commas. Each member initializer shall name an accessible field or property of the object being initialized, followed by an equals sign and an expression or an object initializer or collection initializer. It is an error for an object initializer to include more than one member initializer for the same field or property. It is not possible for the object initializer to refer to the newly created object it is initializing.
+An object initializer consists of a sequence of member initializers, enclosed by `{` and `}` tokens and separated by commas. Each *member_initializer* shall designate a target for the initialization. An *identifier* shall name an accessible field or property of the object being initialized, whereas an *argument_list* enclosed in square brackets shall specify arguments for an accessible indexer on the object being initialized. It is an error for an object initializer to include more than one member initializer for the same field or property.


Is it worth explicitly noting that it is okay to specify multiple member initializers that use indexers?

Given it’s an error if the same field or property is initialised twice then yes something should be said about indexers – but what are the rules? Are the argument_list’s required to be distinct (as with fields/properties) or can the same indexed value be initialised more than once?

Meeting notes: Yes, we want to spell this out, but we can do so in a follow-up PR.

standard/expressions.md

jskeet · 2021-02-05T14:37:24Z

(Removed label as there are suggestions/comments that haven't been addressed. Let's get that tidied up before reviewing.)

An edit for await in catch and finally clauses (#3) snuck into this PR

jskeet · 2021-12-15T20:07:59Z

standard/expressions.md

 ```

-An object initializer consists of a sequence of member initializers, enclosed by `{` and `}` tokens and separated by commas. Each member initializer shall name an accessible field or property of the object being initialized, followed by an equals sign and an expression or an object initializer or collection initializer. It is an error for an object initializer to include more than one member initializer for the same field or property. It is not possible for the object initializer to refer to the newly created object it is initializing.
+An object initializer consists of a sequence of member initializers, enclosed by `{` and `}` tokens and separated by commas. Each *member_initializer* shall designate a target for the initialization. An *identifier* shall name an accessible field or property of the object being initialized, whereas an *argument_list* enclosed in square brackets shall specify arguments for an accessible indexer on the object being initialized. It is an error for an object initializer to include more than one member initializer for the same field or property.


Meeting notes: Yes, we want to spell this out, but we can do so in a follow-up PR.

standard/expressions.md

jskeet

Remaining actions for @BillWagner:

Resolve the conflict
Squash and merge

standard/expressions.md

BillWagner force-pushed the feature-initializer-add branch 3 times, most recently from aea5c23 to e4e4d21 Compare October 26, 2020 20:40

Nigel-Ecma reviewed Nov 18, 2020

View reviewed changes

jskeet added the meeting: discuss This issue should be discussed at the next TC49-TG2 meeting label Nov 18, 2020

jskeet reviewed Nov 18, 2020

View reviewed changes

This was referenced Nov 30, 2020

initialization of an accessible indexer #48

Closed

Collection initializers may use an extension method for Add #59

Closed

jskeet reviewed Dec 16, 2020

View reviewed changes

standard/expressions.md Outdated Show resolved Hide resolved

jskeet removed the meeting: discuss This issue should be discussed at the next TC49-TG2 meeting label Feb 5, 2021

RexJaeschke added this to the C# 6 milestone Mar 17, 2021

BillWagner force-pushed the feature-initializer-add branch from 166d458 to 1c2f2c1 Compare March 17, 2021 14:21

BillWagner added 2 commits November 17, 2021 16:09

specification for initializers

37e3a9c

revert a mistaken edit

f2484b9

An edit for await in catch and finally clauses (#3) snuck into this PR

BillWagner force-pushed the feature-initializer-add branch from 1c2f2c1 to f2484b9 Compare November 17, 2021 21:10

BillWagner and others added 3 commits November 17, 2021 16:18

fix merge mistakes.

3dc0a92

one more merge mistake.

20edf79

Avoid "index initializer" as a non-defined term

1a2d744

jskeet reviewed Dec 15, 2021

View reviewed changes

Require Add to be a method, not a property.

b996065

jskeet approved these changes Dec 15, 2021

View reviewed changes

BillWagner commented Dec 15, 2021

View reviewed changes

standard/expressions.md Outdated Show resolved Hide resolved

Update standard/expressions.md

c1e9e44

jskeet mentioned this pull request Dec 15, 2021

Clarify that indexers can be used multiple times in object initializers #411

Closed

BillWagner added 2 commits December 15, 2021 16:14

Merge branch 'draft-v6' into feature-initializer-add

252c19f

fix section reference.

eed6370

BillWagner merged commit 175ce90 into draft-v6 Dec 15, 2021

BillWagner deleted the feature-initializer-add branch December 15, 2021 21:23

C# 6.0 feature: collection (index) initializers, and extension add method for initializers. #8

C# 6.0 feature: collection (index) initializers, and extension add method for initializers. #8

Uh oh!

Conversation

BillWagner commented Oct 23, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Nigel-Ecma Dec 16, 2020 • 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!

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!

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!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jskeet commented Feb 5, 2021

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

jskeet left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Nigel-Ecma Dec 16, 2020 •

edited

Loading