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

Handle flexible type protocols appropriately #3165

Closed
eholk opened this issue Aug 9, 2012 · 4 comments
Closed

Handle flexible type protocols appropriately #3165

eholk opened this issue Aug 9, 2012 · 4 comments
Labels
A-concurrency Area: Concurrency A-syntaxext Area: Syntax extensions C-enhancement Category: An issue proposing an enhancement or a PR with one.

Comments

@eholk
Copy link
Contributor

eholk commented Aug 9, 2012

Pipe protocols allow for some rather magical things regarding types. For example, consider this protocol:

proto! type_switch {

    start:send {
        get_int -> wait_thing<int>,
        get_str -> wait_thing<~str>
    }

    wait_thing:recv<T:send> {
        thing(T) -> start
    }

}

Furthermore, start could be polymorphic itself and go to different instances of wait_thing.

This is really flexible. Whether this flexibility is desirable is definitely a valid question.

If we decide we do want this flexibility, the protocol compiler needs to be sure to handle this correctly. I think compiling that protocol as an unbounded protocol would probably work fine, but the bounded version will probably fail in mysterious ways.

If we decide we don't want that flexible of polymorphic protocols, we should change the item macro syntax so we can do this instead:

proto! type_switch<T: send> {

    start:send {
        get -> wait_thing
    }

    wait_thing {
        thing(T) -> start
    }
}
@bblum
Copy link
Contributor

bblum commented Aug 14, 2012

this seems really slick. currently you would have to monomorphise the protocol by hand, right?

@eholk
Copy link
Contributor Author

eholk commented Aug 15, 2012

@bblum, we already do polymorphic protocols and monomorphization. The problem is the protocol compiler won't handle the more esoteric cases correctly. It's also more verbose, since you have to put type bounds on each state rather than for the whole protocol.

@graydon
Copy link
Contributor

graydon commented May 1, 2013

Work on this should wait on resolution to #3658

@emberian
Copy link
Member

emberian commented Aug 5, 2013

The pipes compiler was removed, closing.

@emberian emberian closed this as completed Aug 5, 2013
bors pushed a commit to rust-lang-ci/rust that referenced this issue May 15, 2021
fix alignment of a struct's fields with the visual style
saethlin pushed a commit to saethlin/rust that referenced this issue Nov 17, 2023
celinval pushed a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
Dependency upgrade resulting from `cargo update`.

Co-authored-by: tautschnig <1144736+tautschnig@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-concurrency Area: Concurrency A-syntaxext Area: Syntax extensions C-enhancement Category: An issue proposing an enhancement or a PR with one.
Projects
None yet
Development

No branches or pull requests

4 participants