Prepare runway for RFC 809 (overloaded box/placement-in) #23002
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
This is the kind of change that one is expected to need to make to accommodate overloaded-`box`. ---- Note that this is not *all* of the changes necessary to accommodate Issue 22181. It is merely the subset of those cases where there was already a let-binding in place that made it easy to add the necesasry type ascription. (For unnamed intermediate `Box` values, one must go down a different route; `Box::new` is the option that maximizes portability, but has potential inefficiency depending on whether the call is inlined.) ---- There is one place worth note, `run-pass/coerce-match.rs`, where I used an ugly form of `Box<_>` type ascription where I would have preferred to use `Box::new` to accommodate overloaded-`box`. I deliberately did not use `Box::new` here, because that is already done in coerce-match-calls.rs. ---- Precursor for overloaded-`box` and placement-`in`; see Issue 22181.
(You shouldn't use it, but it is a semi-reasonable way to annotate types when necessary.)
|
🙀 |
|
(also, I can predict that this PR as posted (commit 56e83b3be ) and PR #22873 are going to hit a merge conflict, e.g. due to my change to this line, which is just too close to the changes from #22873. I plan to just remove the files that conflict from this PR as best I can (i.e. delaying those changes for the rest of the landing), so that everything can go swimmingly if PR #22873 actually lands.) |
pnkfelix
force-pushed
the
fsk-box-place-runway
branch
from
56e83b3 to
392e673
Compare
|
@bors r=nikomatsakis 392e673 |
|
@bors p=1 |
Many of the modifications putting in `Box::new` calls also include a pointer to Issue 22405, which tracks going back to `box <expr>` if possible in the future. (Still tried to use `Box<_>` where it sufficed; thus some tests still have `box_syntax` enabled, as they use a mix of `box` and `Box::new`.) Precursor for overloaded-`box` and placement-`in`; see Issue 22181.
pnkfelix
force-pushed
the
fsk-box-place-runway
branch
from
392e673 to
0d5bcb1
Compare
bors
added a commit
that referenced
this pull request
Mar 3, 2015
Runway for RFC 809 (overloaded box/placement-in) by adding type annotations or explicit calls to `Box::new` where I found it necessary on PR #22086. I have broken this up into more than one PR because the entire commit chain (see PR #22086) is long, widespread and unwieldy to rebase frequently. To my knowledge this is not a breaking change. Also, there is in principle nothing stopping someone from reverting some/all of these annotations, since without the rest of the commit chain in #22086, the associated code would continue to compile. All I can do is ask: Try to discourage others from removing seemingly "unnecessary" uses of the `Box` type or the `Box::new()` function, until the rest of RFC 809 lands.
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.
Runway for RFC 809 (overloaded box/placement-in) by adding type annotations or explicit calls to
Box::newwhere I found it necessary on PR #22086.I have broken this up into more than one PR because the entire commit chain (see PR #22086) is long, widespread and unwieldy to rebase frequently.
To my knowledge this is not a breaking change. Also, there is in principle nothing stopping someone from reverting some/all of these annotations, since without the rest of the commit chain in #22086, the associated code would continue to compile.
All I can do is ask: Try to discourage others from removing seemingly "unnecessary" uses of the
Boxtype or theBox::new()function, until the rest of RFC 809 lands.