Stream: general

Topic: existential types


Jake Goulding (Apr 27 2019 at 20:48, on Zulip):

What's the one-sentence primary reason for why we can't stabilize existential types today? I'm giving an overview of compiler stuff coming "soon" and want to give a high-level reason why certain things aren't there yet.

Matthew Jasper (Apr 27 2019 at 20:57, on Zulip):

Needs syntax agreement.

Matthew Jasper (Apr 27 2019 at 20:58, on Zulip):

Maybe @oli knows if there are implementation bugs that are blocking as well

Jake Goulding (Apr 27 2019 at 22:43, on Zulip):

That seems encouraging!

Jake Goulding (Apr 27 2019 at 22:44, on Zulip):

I'm on board with the type Foo = impl Bar syntax personally, but I've spent zero time considering rationale. It just "feels" right

oli (Apr 28 2019 at 10:15, on Zulip):

there are some bugs, and loads of diagnostics that need improvement

Tim Diekmann (Apr 30 2019 at 13:09, on Zulip):

I'm on board with the type Foo = impl Bar syntax personally, but I've spent zero time considering rationale. It just "feels" right

It "feels" right but if we want existential type Foo; to be valid, there is no way to express this with the impl Trait syntax.

oli (Apr 30 2019 at 13:16, on Zulip):

There was just a PR forbidding existential type Foo: 'static; and telling you that you need a trait bound just like the diagnostic for impl 'static

centril (Apr 30 2019 at 13:24, on Zulip):

impl 'static could be valid if we wanted it to but it's a rather boring thing to say

centril (Apr 30 2019 at 13:24, on Zulip):

it's possibly useful in APIT

Tim Diekmann (Apr 30 2019 at 13:25, on Zulip):

APIT?

centril (Apr 30 2019 at 13:25, on Zulip):

@Tim Diekmann arg: impl Trait

centril (Apr 30 2019 at 13:25, on Zulip):

@Tim Diekmann blame varkor for the initialisms ;)

Tim Diekmann (Apr 30 2019 at 13:25, on Zulip):

I'll do :D

Tim Diekmann (Apr 30 2019 at 13:27, on Zulip):

However, I don't see, why we don't possibly want existential type Foo; without bound to be valid at some point (not necessarily now).

centril (Apr 30 2019 at 13:28, on Zulip):

@Tim Diekmann it's also a rather boring thing to say; you cannot extract any info out of it

centril (Apr 30 2019 at 13:28, on Zulip):

it's like saying impl Sized

Tim Diekmann (Apr 30 2019 at 13:29, on Zulip):

@centril It's useful for an opaque type returned by any function and to be passed to another function of the same interface

oli (Apr 30 2019 at 13:30, on Zulip):

@Tim Diekmann that's not possible right now. There's no way to reveal the opaque type

oli (Apr 30 2019 at 13:30, on Zulip):

but that's just an implementation detail I guess

centril (Apr 30 2019 at 13:31, on Zulip):

@oli it seems to me that the very essence of an opaque type is that you cannot reveal it :D

centril (Apr 30 2019 at 13:31, on Zulip):

@Tim Diekmann if you truly want to do that, just use existential type Foo: Sized;

oli (Apr 30 2019 at 13:31, on Zulip):

the RFC thinks otherwise

centril (Apr 30 2019 at 13:31, on Zulip):

@oli hmm, reveal in the same module?

oli (Apr 30 2019 at 13:31, on Zulip):

jop

centril (Apr 30 2019 at 13:32, on Zulip):

oh yeah, that's true

centril (Apr 30 2019 at 13:32, on Zulip):

"opaque" has a scope

oli (Apr 30 2019 at 13:32, on Zulip):

I mean I personally would prefer all reveals to have to go through an explicit function

oli (Apr 30 2019 at 13:33, on Zulip):

just to make it clear where the users actually wants to reveal sth

Tim Diekmann (Apr 30 2019 at 13:33, on Zulip):

To make this code work?

mod public_api {
    pub existential type Foo: Sized;

    pub fn give_type() -> Foo {
        return 10_u32;
    }
    pub fn take_type(f: Foo) {
        println!("{}",f)
    }
}

Playground

centril (Apr 30 2019 at 13:33, on Zulip):

@oli I'd just make it work inside the whole module

centril (Apr 30 2019 at 13:33, on Zulip):

and allow partially defining uses

Tim Diekmann (Apr 30 2019 at 13:33, on Zulip):

Tim Diekmann if you truly want to do that, just use existential type Foo: Sized;

Heh, good point

Last update: Nov 20 2019 at 13:45UTC