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.

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

Making it possible to call super trait methods with bound on the subtrait #2

Open
fee1-dead opened this issue Aug 9, 2024 · 1 comment

Comments

@fee1-dead
Copy link
Member

fee1-dead commented Aug 9, 2024

We'll start with the sugar version:

#[const_trait]
trait Foo {
    fn a(&self);
}

#[const_trait]
trait Bar: ~const Foo {}

const fn foo<T: ~const Bar>(t: &T) {
    t.a();
}

This currently fails compilation, and making a desugaring that makes this work is apparently hard. I'll illustrate this issue by first desugaring it.

Note that this desugaring uses some types from a PR that has not yet landed. See this diff for more info.

trait Foo {
    type Fx;
    fn a<const RUNTIME: bool>(&self) where Param<RUNTIME>: Sub<Self::Fx>;
}

trait Bar: Foo {
    type Fx: Sub<<Self as Foo>::Fx>;
}

fn foo<const RUNTIME: bool, T: Bar>(t: &T) where Param<RUNTIME>: Sub<<T as Bar>::Fx> {
    t.a();
}

This errors because the bound on Foo::a isn't satisfied (specifically Param<RUNTIME>: Sub<Self::Fx>) Now one way to do this is maybe make the compiler know that Sub is a transitive trait, such that A: Sub<B>, B: Sub<C> would together imply A: Sub<C>. But that could be very complicated.

I'm not entirely sure how else to approach it. There might be other desugarings that would make this work, but none was able to escape this transitive implication thing I think.

bors added a commit to rust-lang-ci/rust that referenced this issue Sep 29, 2024
…mpiler-errors

properly elaborate effects implied bounds for super traits

Summary: This PR makes it so that we elaborate `<T as Tr>::Fx: EffectsCompat<somebool>` into `<T as SuperTr>::Fx: EffectsCompat<somebool>` when we know that `trait Tr: ~const SuperTr`.

Some discussion at rust-lang/project-const-traits#2.

r? project-const-traits
`@rust-lang/project-const-traits:` how do we feel about this approach?
@PoignardAzur
Copy link

PoignardAzur commented Sep 29, 2024

I'm not entirely sure how else to approach it. There might be other desugarings that would make this work, but none was able to escape this transitive implication thing I think.

Stop me if I'm being naive, but how hard would it be to just hardcode the list of supertraits in the desugared bounds? (Now that's a tongue-twister.)

So your example could desugar to this:

fn foo<const RUNTIME: bool, T: Bar>(t: &T)
where
    Param<RUNTIME>: Sub<<T as Bar>::Fx>,
    Param<RUNTIME>: Sub<<T as Foo>::Fx>,
{
    t.a();
}

It's not super efficient, but I'm pretty sure 99.9% of trait hierarchies in any Rust codebase have under five traits in them, so this solution doesn't add huge amounts of extra work.

EDIT - Oh, this is basically rust-lang/rust#129499

bors added a commit to rust-lang-ci/rust that referenced this issue Sep 30, 2024
…mpiler-errors

properly elaborate effects implied bounds for super traits

Summary: This PR makes it so that we elaborate `<T as Tr>::Fx: EffectsCompat<somebool>` into `<T as SuperTr>::Fx: EffectsCompat<somebool>` when we know that `trait Tr: ~const SuperTr`.

Some discussion at rust-lang/project-const-traits#2.

r? project-const-traits
`@rust-lang/project-const-traits:` how do we feel about this approach?
RalfJung pushed a commit to RalfJung/miri that referenced this issue Oct 3, 2024
…rors

properly elaborate effects implied bounds for super traits

Summary: This PR makes it so that we elaborate `<T as Tr>::Fx: EffectsCompat<somebool>` into `<T as SuperTr>::Fx: EffectsCompat<somebool>` when we know that `trait Tr: ~const SuperTr`.

Some discussion at rust-lang/project-const-traits#2.

r? project-const-traits
`@rust-lang/project-const-traits:` how do we feel about this approach?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants