-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Change precedence of +
in type grammar
#438
Conversation
|
||
```rust | ||
fn foo<F>(f: F) | ||
where F: FnOnce(&int) -> &Object + Send |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, under this scheme, a type written like this is (FnOnce(&int) -> &Object) + Send
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the '->' TYPE
is spurious here, isn't it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
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