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

[varkor]

#![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]

@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]

@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]

@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]

@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]

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]

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

[cofibrant]

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

[oli-obk]

Great!

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

rust/src/librustc_passes/ast_validation.rs

Line 423 in 8af675a

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

rust/src/librustc_passes/ast_validation.rs

Line 575 in 8af675a

_ => {}

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