-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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.
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
where
on trait
declaration should be provided when the trait is an input bound, but is instead a requirement
#103387
Comments
The only trait bounds that are implied ("elaborated" in rustc terminology) are supertrait bounds or |
I agree that this veers close to being a new feature rather than a bug. However, since And as I just found out, nightly trait aliases do provide elaborated bounds for non- #![feature(trait_alias)]
pub trait Trait {}
pub trait WithAssoc {
type Assoc;
}
pub trait WithBoundAssoc = WithAssoc where <Self as WithAssoc>::Assoc: Trait;
// pub trait WithBoundAssoc: WithAssoc where Self::Assoc: Trait {}
pub struct S<T: WithBoundAssoc>(T::Assoc); Obviously I think the trait alias behavior is more intuitive. using that for a workaround#[cfg(trait_alias)]
pub trait WithBoundAssoc = WithAssoc where <Self as WithAssoc>::Assoc: Trait;
#[doc(hidden)]
#[cfg(not(trait_alias)]
pub trait WithBoundAssoc: WithAssoc<Assoc = Self::__Assoc> {
type __Assoc: Trait;
}
#[doc(hidden)]
#[cfg(not(trait_alias)]
impl<T: WithAssoc> WithBoundAssoc for T where Self::Assoc: Trait {
type __Assoc = Self::Assoc;
} This might unfortunately be technically a breaking change to the language, though, since because the @rustbot label +C-feature-request |
I wonder if that trait alias example is a bug, lol. Or, at least, I'm not exactly sure if we should be treating where clauses on trait aliases as supertraits 🤔 |
IIUC, |
Makes sense. |
I believe this basically is a subset of the more general idea of implied bounds. Adding a bit more context, are trait items are different from struct items w.r.t. implied/elaborated bounds?By current standard Rust API design convention, generic bounds should only be added to the
I don't know what the proper thing is to do with this issue at this point. |
After some search I found this issue is actually aged, which can be traced back to 2015. Related issues and questionsInconsistency in type checking where clauses in trait definition #28055#28055 by @malbarbo is got closed in 12 hours:
However, the issue author is not convinced. His comment has received 8 👍🏼s including me.
There is a related question on Stack Overflow. Eric Langlois gives a workaround using a helper trait. On the other hand, this issue spawned rust-lang/reference#504 for documenting this behavior. But until now no one has actually written the doc. Trait bounds for generic types do not imply themselves when they restrict associated types #109325#109325 is asked recently for the same thing. Where @compiler-errors Replies with:
My opinionWhile it's possible to satisfy some user's requirements using trait alias, I agree with @CAD97 that it is a subset of implied bounds, and should be implied without explicitly writing |
I think this is actually a duplicate of #20671 as well; that thread mentions the same workaround too. I just ran into this, unfortunately with GATs this time. Unfortunately the workaround doesn't seem to work with GATs for some reason (Playground): pub trait Trait {}
pub trait WithAssoc {
type Assoc<'a>;
}
pub trait WithBoundAssoc: for<'a> WithAssoc<Assoc<'a> = Self::__Assoc<'a>> {
type __Assoc<'a>: Trait;
}
impl<T: WithAssoc> WithBoundAssoc for T
where
for<'a> Self::Assoc<'a>: Trait,
{
type __Assoc<'a> = Self::Assoc<'a>;
}
It does compile successfully with trait aliases (Playground): #![feature(trait_alias)]
pub trait Trait {}
pub trait WithAssoc {
type Assoc<'a>;
}
pub trait WithBoundAssoc = WithAssoc where for<'a> <Self as WithAssoc>::Assoc<'a>: Trait; It seems like there's no real way to get elaborated bounds for GATs in stable Rust, which is super unfortunate. :/ Does anyone know if this is possible? Is the "overflow evaluating the requirement" error a bug? |
I tried this code: [playground]
I expected this to compile. Instead, it gives the following error:
Meta
playground 1.66.0-nightly (2022-10-21 5c8bff7)
The text was updated successfully, but these errors were encountered: