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

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

Closed
varkor opened this issue Aug 5, 2018 · 8 comments
Closed

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

varkor opened this issue Aug 5, 2018 · 8 comments

Comments

@varkor
Copy link
Member

@varkor 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
Copy link
Member Author

@varkor 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
Copy link
Contributor

@jonhoo 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
Copy link
Contributor

@oli-obk 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
Copy link
Contributor

@jonhoo 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
Copy link
Member Author

@varkor 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
Copy link
Contributor

@oli-obk oli-obk commented Jan 25, 2019

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

@doctorn
Copy link
Contributor

@doctorn doctorn commented Feb 25, 2019

Hello! I'd like to take a look at this

@oli-obk
Copy link
Contributor

@oli-obk oli-obk commented Feb 26, 2019

Great!

So the error for fn foo() -> impl 'static is generated in

self.err_handler().span_err(ty.span, "at least one trait must be specified");

I'm guessing that all that's needed is to replicate the same thing for ItemKind::Existential in

Maybe pull out the check into a method that you can call from both sites

@varkor varkor added the E-easy label Apr 22, 2019
Centril added a commit to Centril/rust that referenced this issue Apr 30, 2019
…e, r=oli-obk

Require a trait in the bounds of existential types

Fixes rust-lang#53090

r? @oli-obk
Centril added a commit to Centril/rust that referenced this issue Apr 30, 2019
…e, r=oli-obk

Require a trait in the bounds of existential types

Fixes rust-lang#53090

r? @oli-obk
Centril added a commit to Centril/rust that referenced this issue Apr 30, 2019
…e, r=oli-obk

Require a trait in the bounds of existential types

Fixes rust-lang#53090

r? @oli-obk
Centril added a commit to Centril/rust that referenced this issue May 2, 2019
…e, r=oli-obk

Require a trait in the bounds of existential types

Fixes rust-lang#53090

r? @oli-obk
Centril added a commit to Centril/rust that referenced this issue May 3, 2019
…e, r=oli-obk

Require a trait in the bounds of existential types

Fixes rust-lang#53090

r? @oli-obk
@bors bors closed this in #60409 May 3, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

4 participants