WIP: Allocator- and fallibility-polymorphic collections #52420
Conversation
|
(rust_highfive has picked a reviewer for you, use r? to override) |
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
8d1c966 to
afe0269
Compare
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
|
|
||
| /// The type of any errors thrown by the allocator, customarily | ||
| /// either `AllocErr`, for when error recovery is allowed, or `!` | ||
| /// to signify that all errors will result in . |
There was a problem hiding this comment.
The last word of this sentence is missing.
This turns `Box<T>` into `Box<T, A: Alloc = Global>`. This is a minimalist change to achieve this, not touching anything that could have backwards incompatible consequences like requiring type annotations in places where they currently aren't required, per rust-lang#50822 (comment)
We will use this for fallibility polymorphism
See its documentation for why its useful
afe0269 to
9a1f94d
Compare
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
|
Thanks for the PR @Ericson2314! I think at this time though the libs team doesn't have the bandwidth to review and land this before the 2018 edition. This is a very large step for us to take which we want to be sure to take carefully. Would it be possible to postpone this until after the 2018 edition has released? |
|
I suppose that's fine. When is that likely to be? I'd just like the fact that there's work done towards this to affect decisions like Alloc stabilization. (I don't think I actually need to break any APIs, but let this show that many long-standing issues with alloc are in fact resolvable, so who knows what else a deep dive would turn up.) |
|
If at least #50882 can not be blocked, that would help me keep this up-to-date in the meantime. |
|
#50882 AFAIK is largely technically blocked on the regression in error messages, but it's basically in the same boat as this PR in that it requires some discussion and design which the libs team doesn't have the bandwidth for right now, but after the edition 2018 release we can revisit. |
|
#50882 is not blocked on regression in error messages anymore. It's blocked on one test failing in what looks like a race condition, and that only happens when building with LLVM 5. |
|
@glandium er sorry but that PR is also large enough and contentious enough that we're not going to be able to land it before the edition, I'll comment over there though. |
|
Making |
|
Sure I do not expect this one to be merged quickly, only to provide a concrete example of what I am talking about. |
|
Triage: Based on the comments above I'm closing this PR and marking it |
|
Now the 2018 edition is landed. The PR could be reopened. |
This picks up where #50882 will leave off, adding allocator parameters to the other collections. It also adds and associated error type for allocation, so as to enable fallibility-polymorphic code and support the few
impls and other functions which require "infallible" allocation.When done, should convert all the collections for #42774
Unfortunately, as documented in #52396, I had to make an
AllocHelpertrait in order to get mydefault implto work.Also,edit fixed withOK(_): Result<T, !>is no longer deemed and infallible pattern so mylet Ok(..) = ..;doesn't work. I can switch it to something else, but I'd like to make sure that's intentional first.exhaustive_patterns.