Nest the impl Trait existential item inside the return type

[oli-obk]

fixes #54045

r? @cramertj

[rust-highfive]

The job x86_64-gnu-llvm-5.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

[cramertj]

Nice!

@bors r+

[bors]

📌 Commit c3151c6 has been approved by cramertj

[bors]

⌛ Testing commit c3151c6 with merge 2155f27...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: cramertj
Pushing 2155f27 to master...

[eddyb]

I want something like this in general, maybe {...} block syntax for types?
Then -> impl Trait would be -> { existential type X: Trait; X }.
cc @Centril @nikomatsakis

[Centril]

In other words this would be legal?

type Foo = { u8 };

Not sure why it is useful tho...

[oli-obk]

isn't that essentially generic modules? (but unnamed)

[eddyb]

@oli-obk I guess only if you can depend on parameters in scope.

@Centril for the same reason we have it for expressions :P.

[oli-obk]

I guess only if you can depend on parameters in scope.

which impl trait always does

[Centril]

@eddyb in exprs it exists for some sort of encapsulation purposes... I suppose you could do some sort of encapsulation of type aliases... but we should tread carefully here, there might be ambiguity in store.

PS: we should move this conversation elsewhere into a fresh issue / internals instead of comments on a merged PR (totally not discoverable...).

[cramertj]

@Centril

I suppose you could do some sort of encapsulation of type aliases

Module-based encapsulation is how existential type X: Trait; works today.

[Centril]

@cramertj I meant something like this:

type Foo = {
    type ComplexType = Bar<Baz<u8>>;
    Vec<ComplexType>
};