Skip to content

Update section on "existential type" to "opaque type" #402

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

Merged
merged 1 commit into from
Aug 29, 2019
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
48 changes: 0 additions & 48 deletions src/existential-types.md

This file was deleted.

62 changes: 62 additions & 0 deletions src/opaque-types-type-alias-impl-trait.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,62 @@
# Opaque types (type alias `impl Trait`)

Opaque types are syntax to declare an opaque type alias that only
exposes a specific set of traits as their interface; the concrete type in the
background is inferred from a certain set of use sites of the opaque type.

This is expressed by using `impl Trait` within type aliases, for example:

```rust,ignore
type Foo = impl Bar;
```

This declares an opaque type named `Foo`, of which the only information is that
it implements `Bar`. Therefore, any of `Bar`'s interface can be used on a `Foo`,
but nothing else (regardless of whether it implements any other traits).

Since there needs to be a concrete background type, you can currently
express that type by using the opaque type in a "defining use site".

```rust,ignore
struct Struct;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't it be struct Foo; ?

Copy link
Member Author

@varkor varkor Sep 17, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes it should! Feel free to open a PR with a fix :)

Edit: I misread. See comment below.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then the whole example should be

fn foo() -> impl Bar {
    struct Foo;
    impl Bar for Foo { /* stuff */ }
    Foo
}

?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I misread earlier. Really, this code snippet should be read in the context of the previous one. But that's confusing, so maybe we should add the definition of Foo here too. So the complete snippet would be:

type Foo = impl Bar;

struct Struct;

impl Bar for Struct { /* stuff */ }

fn foo() -> Foo {
    Struct
}

impl Bar for Struct { /* stuff */ }
fn foo() -> Foo {
Struct
}
```

Any other "defining use site" needs to produce the exact same type.

## Defining use site(s)

Currently only the return value of a function can be a defining use site
of an opaque type (and only if the return type of that function contains
the opaque type).

The defining use of an opaque type can be any code *within* the parent
of the opaque type definition. This includes any siblings of the
opaque type and all children of the siblings.

The initiative for *"not causing fatal brain damage to developers due to
accidentally running infinite loops in their brain while trying to
comprehend what the type system is doing"* has decided to disallow children
of opaque types to be defining use sites.

### Associated opaque types

Associated opaque types can be defined by any other associated item
on the same trait `impl` or a child of these associated items. For instance:

```rust,ignore
trait Baz {
type Foo;
fn foo() -> Self::Foo;
}

struct Quux;

impl Baz for Quux {
type Foo = impl Bar;
fn foo() -> Self::Foo { ... }
}
```