Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Should vec::reserve reserve the exact amount or in powers of two? #2071

Closed
brson opened this issue Mar 29, 2012 · 2 comments
Closed

Should vec::reserve reserve the exact amount or in powers of two? #2071

brson opened this issue Mar 29, 2012 · 2 comments
Assignees
@brson

Comments

@brson
Copy link
Contributor

brson commented Mar 29, 2012

Currently it's exact, but there are places in vec that use it in conjuction with next_power_of_two to do it the other way, and #2062 also wants to reserve in powers of two.

Clearly there should be two different versions. Should the default be exact? If so, what should the next_power_of_two version be called?
@brson
Copy link
Contributor Author

brson commented Mar 29, 2012

Jesse suggested reserve_at_least which I think is good. Think I will go ahead and add that and update the documentation on vec::reserve to indicate the exact behavior. Do the same for str::reserve probably.

@ghost ghost assigned brson Mar 29, 2012
@brson
Copy link
Contributor Author

brson commented Mar 29, 2012

Implemented.

@brson brson closed this as completed Mar 29, 2012
@Aaron1011 Aaron1011 mentioned this issue Aug 27, 2019
Merged
Aaron1011 added a commit to Aaron1011/rust that referenced this issue Sep 24, 2019
@Aaron1011
Fix coherence checking for impl trait in type aliases
33e1dd7 
Fixes rust-lang#63677

RFC rust-lang#2071 (impl-trait-existential-types) does not explicitly state how
impl trait type alises should interact with coherence. However, there's
only one choice which makes sense - coherence should look at the
underlying type (i.e. the 'defining' type of the impl trait) of the type
alias, just like we do for non-impl-trait type aliases.

Specifically, impl trait type alises which resolve to a local type
should be treated like a local type with respect to coherence (e.g.
impl trait type aliases which resolve to a forieign type should be
treated as a foreign type, and those that resolve to a local type should
be treated as a local type).

Since neither inherent impls nor direct trait impl (i.e. `impl MyType`
or `impl MyTrait for MyType`) are allowd for type aliases, this
usually does not come up. Before we ever attempt to do coherence
checking, we will have errored out if an impl trait type alias was used
directly in an 'impl' clause.

However, during trait selection, we sometimes need to prove bounds like
'T: Sized' for some type 'T'. If 'T' is an impl trait type alias, this
requires to know the coherence behavior for impl trait type aliases when
we perform coherence checking.

Note: Since determining the underlying type of an impl trait type alias
requires us to perform body type checking, this commit causes us to type
check some bodies easlier than we otherwise would have. However, since
this is done through a query, this shouldn't cause any problems

For completeness, I've added an additional test of the coherence-related
behavior of impl trait type aliases.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@brson brson

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@brson