Refactoring in support of higher-ranked traitbounds #18743
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
|
| lifetime_defs | ||
| /// Parses `[ 'for' '<' lifetime_defs '>' ]' | ||
| fn parse_legacy_lifetime_defs(&mut self, | ||
| lifetime_defs: Vec<ast::LifetimeDef>) |
|
r=me with the nit |
|
@pcwalton added one more commit, 9be076d, which purges |
nikomatsakis
force-pushed
the
hrtb-refactor-2
branch
from
9be076d
to
fc86136
Compare
…naturally carries over to object types. I wanted to embed an `Rc<TraitRef>`, but I was foiled by the current static rules, which prohibit non-Sync values from being stored in static locations. This means that the constants for `ty_int` and so forth cannot be initialized.
nikomatsakis
force-pushed
the
hrtb-refactor-2
branch
from
fc86136
to
091dc6e
Compare
|
rebased, merged a bit |
|
r=me |
bors
added a commit
that referenced
this pull request
Nov 9, 2014
Various miscellaneous changes pushing towards HRTB support: 1. Update parser and adjust ast to support `for<'a,'b>` syntax, both in closures and trait bounds. Warn on the old syntax (not error, for stage0). 2. Refactor TyTrait representation to include a TraitRef. 3. Purge `once_fns` feature gate and `once` keyword. r? @pcwalton This is a [breaking-change]: - The `once_fns` feature is now officially deprecated. Rewrite using normal closures or unboxed closures. - The new `for`-based syntax now issues warnings (but not yet errors): - `fn<'a>(T) -> U` becomes `for<'a> fn(T) -> U` - `<'a> |T| -> U` becomes `for<'a> |T| -> U`
|
@nikomatsakis I only noticed now that rust-lang/rfcs#387 only discusses changing the syntax for Concrete example: fn bar1(g: fn<'a>(x: &'a int) -> &'a int) { g(&3i); }
// ^~~~
//
// Definition of `bar1` now causes rustc to issue a deprecation warning.
fn bar2(g: for<'a> fn(x: &'a int) -> &'a int) { g(&3i); }
// ^~~~~~~
//
// You need to use this syntax instead.
// ... BUT ...
fn foo1<'a>(x: &'a int) -> &'a int { x }
// ^~~~
// This is the only syntax accepted for fn definition forms...
for<'a> fn foo2(x: &'a int) -> &'a int { x } /*
^~~~~~~ *
*
...because this syntax is rejected by rustc. *
*/Is this a problem, in terms of introducing (unnecessary?) deviation between the type and term forms? |
|
( adding reference to the HRTB tracking issue: #18639 ) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Various miscellaneous changes pushing towards HRTB support:
for<'a,'b>syntax, both in closures and trait bounds. Warn on the old syntax (not error, for stage0).once_fnsfeature gate andoncekeyword.r? @pcwalton
This is a [breaking-change]:
once_fnsfeature is now officially deprecated. Rewrite using normal closures or unboxed closures.for-based syntax now issues warnings (but not yet errors):fn<'a>(T) -> Ubecomesfor<'a> fn(T) -> U<'a> |T| -> Ubecomesfor<'a> |T| -> U