Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create speclet for lambda discard parameters #2901

Merged
merged 9 commits into from
Dec 13, 2019
Merged

Conversation

jcouv
Copy link
Member

@jcouv jcouv commented Oct 22, 2019

Relates to championed issue #111


## Detailed design

In a lambda or delegate declaration with more than one parameter named `_`, those parameters are discard parameters.
Copy link
Member

@gafter gafter Oct 25, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This specification does not describe the scoping implications. Is there any hiding? #Closed


## Detailed design

In a lambda or delegate declaration with more than one parameter named `_`, those parameters are discard parameters.
Copy link
Member

@gafter gafter Oct 25, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

delegate declaration [](start = 15, length = 20)

Did you really mean "delegate declaration", that is, a declaration of a delegate type? #Closed


In a lambda or delegate declaration with more than one parameter named `_`, those parameters are discard parameters.

Discard parameters are not in scope in the body of the lambda or delegate. So they cannot be accessed.
Copy link
Member

@gafter gafter Oct 25, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

parameters are not in scope [](start = 8, length = 27)

Can you pose this as a set of changes to the language specification, e.g. name lookup? #Resolved

Copy link
Member Author

@jcouv jcouv Oct 25, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I took a stab at this:

In the section on method parameters and scopes, I would say that discard parameters do not add any names in scope.
In the section on corresponding parameters, I would say that named arguments do not correspond to discard parameters. #Resolved


## Detailed design

In a parameter list with more than one parameter named `_`, such parameters are discard parameters.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

more than one parameter named _ [](start = 24, length = 34)

The spec currently makes this an error. What spec changes are proposed to make it not be an error.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"It is an error for two members of a method declaration space to have the same name." (method parameters).

I'll update speclet to say that discard parameters don't have a name (so the above rule doesn't apply).

In a parameter list with more than one parameter named `_`, such parameters are discard parameters.
Note: if a single parameter is named `_` then it is a regular parameter for backwards compatibility reasons.

Discard parameters do not introduce any names to any scopes.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do not introduce any names to any scopes [](start = 19, length = 40)

What name lookup changes are proposed to implement this intent in the specification?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Which section of the spec do you refer to for "name lookup"?
I think I'm proposing that we don't change name lookup, but rather we change what names are added to what scopes.
"Names are introduced into this declaration space by the type parameter list and the formal parameter list of the method and by local variable declarations in the block of the method." (method parameters) would be affected by the rule that discard parameters don't introduce a name in any scope.

In the parameter list of a lambda or anonymous method with more than one parameter named `_`, such parameters are discard parameters.
Note: if a single parameter is named `_` then it is a regular parameter for backwards compatibility reasons.

Discard parameters do not introduce any names to any scopes.
Copy link
Member

@gafter gafter Nov 3, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

introduce any names to any scopes [](start = 26, length = 33)

Please identify the intended change to 8.7 Scopes.

You will need to modify the name lookup rules to cause this intent to be reified in the specification. For example, we have the following text in ECMA's 12.7.3 Simple Names (giving the meaning of a simple name as an expression):

  • If K is zero and the simple-name appears within a block and if the block’s (or an enclosing block’s) local variable declaration space (§8.3) contains a local variable, parameter or constant with name I, then the simple-name refers to that local variable, parameter or constant and is classified as a variable or value.

Note that the discard parameter is in the declaration space by 8.3, and is a parameter named _ (see line 16 above), so without a change to the quoted paragraph it is indeed found during name lookup. Please identify the intended changes to the specification. #Resolved

@jcouv jcouv requested a review from gafter December 6, 2019 22:29
@jcouv
Copy link
Member Author

jcouv commented Dec 13, 2019

@gafter I'll go ahead and merge. Feel free to provide further comments. I'll address separately. Thanks

@jcouv jcouv merged commit 42ef673 into master Dec 13, 2019
@jcouv jcouv deleted the dev/jcouv/lambda-discards branch December 13, 2019 21:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants