~const trait and projection bounds do not imply their non-const counterparts
#119721
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
rustbot
added
S-waiting-on-review
rust-cloud-vms
bot
force-pushed
the
constness-implication
branch
from
b3067c4
to
ab364e2
Compare
fmease
reviewed
Jan 7, 2024
tests/ui/rfcs/rfc-2632-const-trait-impl/assoc-type-const-bound-usage.stderr
Show resolved
Hide resolved
rust-cloud-vms
bot
force-pushed
the
constness-implication
branch
from
ab364e2
to
f36ddf2
Compare
This comment has been minimized.
This comment has been minimized.
rust-cloud-vms
bot
force-pushed
the
constness-implication
branch
from
f36ddf2
to
99292c9
Compare
This comment has been minimized.
This comment has been minimized.
rust-cloud-vms
bot
force-pushed
the
constness-implication
branch
from
99292c9
to
d2f2a24
Compare
This comment has been minimized.
This comment has been minimized.
rust-cloud-vms
bot
force-pushed
the
constness-implication
branch
from
d2f2a24
to
760673e
Compare
|
@bors r+ |
bors
added
S-waiting-on-bors
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jan 9, 2024
…llaumeGomez Rollup of 5 pull requests Successful merges: - rust-lang#118241 (Making `User<T>` and `User<[T]>` `Send`) - rust-lang#118645 (chore: Bump compiler_builtins) - rust-lang#118680 (Add support for shell argfiles) - rust-lang#119721 (`~const` trait and projection bounds do not imply their non-const counterparts) - rust-lang#119768 (core: panic: fix broken link) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jan 9, 2024
Rollup merge of rust-lang#119721 - compiler-errors:constness-implication, r=fee1-dead `~const` trait and projection bounds do not imply their non-const counterparts This PR removes the hack where we install a non-const trait and projection bound for every `const_trait` and `~const` projection bound we have in the AST. It ends up messing up more things than it fixes, see words below. Fixes rust-lang#119718 cc `@fmease` `@fee1-dead` `@oli-obk` r? fee1-dead or one of y'all i don't care --- My understanding is that this hack was added to support the following code: ```rust pub trait Owo<X = <Self as Uwu>::T> {} #[const_trait] pub trait Uwu: Owo {} ``` Which is concretely lifted from in the `FromResidual` and `Try` traits. Since within the param-env of `trait Uwu`, we only know that `Self: ~const Uwu` and not `Self: Uwu`, the projection `<Self as Uwu>::T` is not satsifyable. This causes problems such as rust-lang#119718, since instantiations of `FnDef` types coming from `const fn` really do **only** implement one of `FnOnce` or `const FnOnce`! --- In the long-term, I believe that such code should really look something more like: ```rust #[const_trait] pub trait Owo<X = <Self as ~const Uwu>::T> {} #[const_trait] pub trait Uwu: Owo {} ``` ... and that we should introduce some sort of `<T as ~const Foo>::Bar` bound syntax, since due to the fact that `~const` bounds can be present in item bounds, e.g. ```rust #[const_trait] trait Foo { type Bar: ~const Destruct; } ``` It's easy to see that `<T as Foo>::Bar` and `<T as ~const Foo>::Bar` (or `<T as const Foo>::Bar`) can be distinct types with distinct item bounds! **Admission**: I know I've said before that I don't like `~const` projection syntax, I do at this point believe they're necessary to fully express bounds and types in a maybe-const world.
4 tasks
fee1-dead
added
F-const_trait_impl
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.
This PR removes the hack where we install a non-const trait and projection bound for every
const_traitand~constprojection bound we have in the AST. It ends up messing up more things than it fixes, see words below.Fixes #119718
cc @fmease @fee1-dead @oli-obk
r? fee1-dead or one of y'all i don't care
My understanding is that this hack was added to support the following code:
Which is concretely lifted from in the
FromResidualandTrytraits. Since within the param-env oftrait Uwu, we only know thatSelf: ~const Uwuand notSelf: Uwu, the projection<Self as Uwu>::Tis not satsifyable.This causes problems such as #119718, since instantiations of
FnDeftypes coming fromconst fnreally do only implement one ofFnOnceorconst FnOnce!In the long-term, I believe that such code should really look something more like:
... and that we should introduce some sort of
<T as ~const Foo>::Barbound syntax, since due to the fact that~constbounds can be present in item bounds, e.g.It's easy to see that
<T as Foo>::Barand<T as ~const Foo>::Bar(or<T as const Foo>::Bar) can be distinct types with distinct item bounds!Admission: I know I've said before that I don't like
~constprojection syntax, I do at this point believe they're necessary to fully express bounds and types in a maybe-const world.