-
Notifications
You must be signed in to change notification settings - Fork 13.4k
orphan check: rationalize our handling of constants #99861
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Conversation
// All possible values for a constant parameter already exist | ||
// in the crate defining the trait, so they are always non-local. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm is const Foo: &dyn Bar
ever even possible? What about <T: Trait, const Foo: T>
?
I think this statement holds today, but if it could ever change in the future, do we have some way to ensure we don't forget about this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤔
T: Trait, const VALUE: T
isn't an issue, because T
has to be forward declared, so if T
is a local type, then the orphan check already succeeds the moment it sees T
for trait objects that's more difficult 😁 or well, it depends on whether we already have local values for const T: fn()
. going to extend that comment.
feel like the value of allowing uncovered const params is still greater then allowing impls to be guarded by a local function pointer 😁 so this impl is still the right one imo
extern crate trait_with_const_param; | ||
use trait_with_const_param::*; | ||
|
||
// Trivial case, const param after local type. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wrong description? "Impl for local type"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in the substs of that impl trait ref we have [Local1, N, T]
, so const param after local type holds 😁
want me to change that comment? don't think that "impl for local type" is the right descr because the same also holds for impl<const N: usize, T> OtherTrait<Local1, N, T> for ForeignTy
@bors r+ |
Rollup of 6 pull requests Successful merges: - rust-lang#99582 (Delay a span bug if we see ty/const generic params during writeback) - rust-lang#99861 (orphan check: rationalize our handling of constants) - rust-lang#100026 (Add `Iterator::array_chunks` (take N+1)) - rust-lang#100115 (Suggest removing `let` if `const let` or `let const` is used) - rust-lang#100126 (rustc_target: Update some old naming around self contained linking) - rust-lang#100487 (`assert_{inhabited,zero_valid,uninit_valid}` intrinsics are safe) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
cc @rust-lang/types @rust-lang/project-const-generics on whether you agree with this reasoning.
r? types