[Version 10.0] Feature support for lambda improvements#1566
[Version 10.0] Feature support for lambda improvements#1566RexJaeschke wants to merge 7 commits intodraft-10from
Conversation
RexJaeschke
added
type: feature
|
|
||
| - If `E` is a tuple expression with arity `N` and elements `Eᵢ`, and `T` is a tuple type with arity `N` with corresponding element types `Tₑ` or `T` is a nullable value type `T0?` and `T0` is a tuple type with arity `N` that has a corresponding element type `Tₑ`, then for each `Eᵢ` an output type inference is made from `Eᵢ` to `Tₑ`. | ||
| - If `E` is an anonymous function with inferred return type `U` ([§12.6.3.14](expressions.md#126314-inferred-return-type)) and `T` is a delegate type or expression tree type with return type `Tₓ`, then a *lower-bound inference* ([§12.6.3.11](expressions.md#126311-lower-bound-inferences)) is made *from* `U` *to* `Tₓ`. | ||
| - **TBD** If `E` is an anonymous function with inferred return type `U` ([§12.6.3.14](expressions.md#126314-inferred-return-type)) and `T` is a delegate type or expression tree type with return type `Tₓ`, then a *lower-bound inference* ([§12.6.3.11](expressions.md#126311-lower-bound-inferences)) is made *from* `U` *to* `Tₓ`. |
There was a problem hiding this comment.
Should anything be added here? The MS spec replacement text was written before we created the separate input and output type inference sections. And I added the proposed text from the MS spec to the input inference section only.
|
|
||
| #### 12.6.3.16 Finding the best common type of a set of expressions | ||
|
|
||
| **TBD** |
There was a problem hiding this comment.
The MS spec says, “Best common type: Best common type is defined in terms of type inference so the type inference changes above apply to best common type as well."
Someone needs to figure out what changes go in this section.
standard/expressions.md
Outdated
|
|
||
| Given an implicit conversion `C₁` that converts from an expression `E` to a type `T₁`, and an implicit conversion `C₂` that converts from an expression `E` to a type `T₂`, `C₁` is a ***better conversion*** than `C₂` if `E` does not exactly match `T₂` and at least one of the following holds: | ||
|
|
||
| - `C1` is not a _function_type_conversion_ and `C2` is a _function_type_conversion_, or |
There was a problem hiding this comment.
This list has been changed since the MS spec was written, and the proposed changes do not match the new organization. I have added the proposed new item at the front of the list, but someone will need to see if that is now the correct text and is in the right place.
| > *Note*: For historical reasons, there are two syntactic flavors of anonymous functions, namely *lambda_expression* and *anonymous_method_expression*. For almost all purposes, *lambda_expression* is more concise and expressive than *anonymous_method_expression*s, which remain in the language for backwards compatibility. *end note* | ||
|
|
||
| ```ANTLR | ||
| lambda_expression |
There was a problem hiding this comment.
The grammar in the MS proposal is quite different from what we actually have in V8, as in V7 we added ref returns. The MS proposal is also missing grammar edits for an explicit return type (see below). It also appears to support default values on parameters, something that was not added until V12.
My edits to support an optional return type need close review, esp. now that we have ref and non-ref returns. I modelled these edits on the analogous method_declaration grammar rule (§15.6.1), which uses 2 subrules, but in each requires a return type be specified, which is not the case with lambdas where that is optional. Also, that pair of rules uses different bodies (method_body and ref_method_body) whereas I have not for lambda-expression, but perhaps we’ll need to add something like anonymous_ref_function_body as well, and possibly change the existing definition of anonymous_function_body.
At a glance, it seems that rule 'ref' variable_reference should not be allowed in anonymous_function_body if that rule is reached from a lambda_expression having return_type, but what if no return type is specified at all, and is simply inferred?
I think it likely that my proposed grammar changes will need to be tweaked and/or possibly augmented with constraints in the narrative.
|
|
||
| An anonymous function `F` shall always be converted to a delegate type `D` or an expression-tree type `E`, either directly or through the execution of a delegate creation expression `new D(F)`. This conversion determines the result of the anonymous function, as described in [§10.7](conversions.md#107-anonymous-function-conversions). | ||
|
|
||
| ### §anon-func-type Anonymous function type |
There was a problem hiding this comment.
The MS proposal introduces the term function_type. I have two objections to that spelling: First, the separating underscore doesn’t seem right; it makes the name look like a grammar rule name. Second, “function” is a very general term, so I called the new term “anonymous function type” instead, as it applies only in that narrow context.
| The following conversions are permitted from an anonymous function type `F`(§anon-func-type): | ||
|
|
||
| - To an anonymous function type `G` if the parameters and return types of `F` are variance-convertible to the parameters and return type of `G`. | ||
| - To `System.Delegate` or its base classes or interfaces. |
There was a problem hiding this comment.
The MS proposal mentions System.MulticastDelegate. However, as we don’t have that type in our spec, I replaced all such mentions with System.Delegate.
1 participant
This is Rex's adaptation of the corresponding MS proposal.
The MS spec proposal ends with an "Open issue" section, which does not say anything about the eventual disposition of those issues. Someone needs to check if more work was done to address them.