Change precedence of `+` in type grammar #438
Conversation
|
|
||
| ```rust | ||
| fn foo<F>(f: F) | ||
| where F: FnOnce(&int) -> &Object + Send |
huonw
Nov 4, 2014
Member
So, under this scheme, a type written like this is (FnOnce(&int) -> &Object) + Send?
So, under this scheme, a type written like this is (FnOnce(&int) -> &Object) + Send?
nikomatsakis
Nov 4, 2014
Author
Contributor
On Tue, Nov 04, 2014 at 03:16:07AM -0800, Huon Wilson wrote:
So, under this scheme, a type written like this is (FnOnce(&int) -> &Object) + Send?
Yes, right. That might occur in a context like Box<FnOnce(&int) -> &Object + Send>
On Tue, Nov 04, 2014 at 03:16:07AM -0800, Huon Wilson wrote:
So, under this scheme, a type written like this is
(FnOnce(&int) -> &Object) + Send?
Yes, right. That might occur in a context like Box<FnOnce(&int) -> &Object + Send>
|
Looks good to me. |
|
I didn't know how much I wanted this until I saw this RFC, and now I want it. |
| | ... | ||
| | '(' SUM ')' | ||
| SUM = TYPE { '+' TYPE } | ||
| PATH = IDS '<' SUM { ',' SUM } '>' '->' TYPE |
ben0x539
Nov 5, 2014
the '->' TYPE is spurious here, isn't it?
the '->' TYPE is spurious here, isn't it?
nikomatsakis
Nov 6, 2014
Author
Contributor
On Wed, Nov 05, 2014 at 08:26:51AM -0800, Benjamin Herr wrote:
the '->' TYPE is spurious here, isn't it?
Yes, thanks. I was thinking of the () form.
On Wed, Nov 05, 2014 at 08:26:51AM -0800, Benjamin Herr wrote:
the
'->' TYPEis spurious here, isn't it?
Yes, thanks. I was thinking of the () form.
| | '(' SUM ')' | ||
| SUM = TYPE { '+' TYPE } | ||
| PATH = IDS '<' SUM { ',' SUM } '>' '->' TYPE | ||
| | IDS '(' SUM { ',' SUM } '>' '->' TYPE |
ben0x539
Nov 5, 2014
That should be ')' instead of > I assume?
That should be ')' instead of > I assume?
| SUM = TYPE { '+' TYPE } | ||
| PATH = IDS '<' SUM { ',' SUM } '>' '->' TYPE | ||
| | IDS '(' SUM { ',' SUM } '>' '->' TYPE | ||
| IDS = ID { :: ID } |
ben0x539
Nov 5, 2014
This doesn't account for absolute paths, does it? Also probably wants ' ' around the ::.
This doesn't account for absolute paths, does it? Also probably wants ' ' around the ::.
|
FWIW, |
|
On Wed, Nov 05, 2014 at 05:28:12PM -0800, comex wrote:
Yes. I'd prefer to find a way to address this allows one to omit the |
|
It was brought up in last week's Rust meeting that the precedence of |
|
Accepted. Discussion. More discussion. Tracking. |
syntax: Lower priority of `+` in `impl Trait`/`dyn Trait`
Now you have to write `Fn() -> (impl A + B)` instead of `Fn() -> impl A + B`, this is consistent with priority of `+` in trait objects (`Fn() -> A + B` means `(Fn() -> A) + B`).
To make this viable I changed the syntax to also permit `+` in return types in function declarations
```
fn f() -> dyn A + B { ... } // OK, don't have to write `-> (dyn A + B)`
// This is acceptable, because `dyn A + B` here is an isolated type and
// not part of a larger type with various operator priorities in play
// like `dyn A + B` in `Fn() -> dyn A + B` despite syntax similarities.
```
but you still have to use `-> (dyn A + B)` in function types and function-like trait object types (see this PR's tests for examples).
This can be a breaking change for code using `impl Trait` on nightly. The thing that is most likely to break is `&impl A + B`, it needs to be rewritten as `&(impl A + B)`.
cc #34511 #44662 rust-lang/rfcs#438
syntax: Lower priority of `+` in `impl Trait`/`dyn Trait`
Now you have to write `Fn() -> (impl A + B)` instead of `Fn() -> impl A + B`, this is consistent with priority of `+` in trait objects (`Fn() -> A + B` means `(Fn() -> A) + B`).
To make this viable I changed the syntax to also permit `+` in return types in function declarations
```
fn f() -> dyn A + B { ... } // OK, don't have to write `-> (dyn A + B)`
// This is acceptable, because `dyn A + B` here is an isolated type and
// not part of a larger type with various operator priorities in play
// like `dyn A + B` in `Fn() -> dyn A + B` despite syntax similarities.
```
but you still have to use `-> (dyn A + B)` in function types and function-like trait object types (see this PR's tests for examples).
This can be a breaking change for code using `impl Trait` on nightly. The thing that is most likely to break is `&impl A + B`, it needs to be rewritten as `&(impl A + B)`.
cc #34511 #44662 rust-lang/rfcs#438
Update type grammar to make
+have lower precedence, consistent with the expression grammar, resolving a grammatical ambiguity.Summary of impact (non-normative, from the RFC):
Rendered view