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

`existential type` can accept generic bounds that do not specify a trait #53090

Open
varkor opened this Issue Aug 5, 2018 · 6 comments

Comments

Projects
None yet
3 participants
@varkor
Copy link
Member

varkor commented Aug 5, 2018

#![feature(existential_type)]

existential type Foo: 'static; // ok

fn foo() -> Foo {
    "foo"
}

fn bar() -> impl 'static { // error: at least one trait must be specified
    "foo"
}

fn main() {}

Although the RFC wasn't explicit about this, it seems that this is an oversight, as existential type should function like return-position impl Trait.

@varkor varkor changed the title existential type can accept generic bounds that do not specify a trait `existential type` can accept generic bounds that do not specify a trait Aug 5, 2018

@varkor

This comment has been minimized.

Copy link
Member Author

varkor commented Aug 5, 2018

@rkruppe points out this could be useful when using tokens passed in and out of a module (that is, inside the module in which the existential type is declared, we're able to do whatever we like with it, because the type is transparent, but outside we just have a lifetime bound for convenience).

However, this is only true under the originally-specified behaviour of existential type, which is transparent inside the module in which it is declared. Currently, existential type is always opaque.

@jonhoo

This comment has been minimized.

Copy link
Contributor

jonhoo commented Dec 14, 2018

@varkor I ran into what I believe is the same issue over in #34511:

trait Foo {
    type Assoc;
}

struct Bar;
impl Foo for Bar {
    existential type Assoc;
}

The above doesn't compile. You need to write (note the : ;)

    existential type Assoc: ;
@oli-obk

This comment has been minimized.

Copy link
Contributor

oli-obk commented Jan 25, 2019

@varkor should we maybe close this issue? I think it's fine for existential type to be more powerful than impl Trait in return position. We only need to be able to desugar impl Trait to existential type, there's no obligation in the opposite direction

@jonhoo

This comment has been minimized.

Copy link
Contributor

jonhoo commented Jan 25, 2019

@oli-obk that seems reasonable to me, although I do think the parsing issue above ought to be fixed (though that's probably a separate issue).

@varkor

This comment has been minimized.

Copy link
Member Author

varkor commented Jan 25, 2019

There's nothing wrong in practice with existential type being more expressive, but it doesn't seem useful to allow pure lifetime bounds in existential type or impl Trait. Even though it's possible for them to be different, I don't see a good reason they should be. I still think we should apply the same error for existential type (and then potentially relax it later if we find that it's useful).

Edit: also note that this does become confusing if the final syntax for existential type is impl Trait, as this then behaves differently in different circumstances.

@oli-obk

This comment has been minimized.

Copy link
Contributor

oli-obk commented Jan 25, 2019

Oh yea, I'd be perfectly happy with requiring a trait in the bounds of existential types.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment