-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Comments
this seems really slick. currently you would have to monomorphise the protocol by hand, right? |
@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. |
Work on this should wait on resolution to #3658 |
The pipes compiler was removed, closing. |
fix alignment of a struct's fields with the visual style
Dependency upgrade resulting from `cargo update`. Co-authored-by: tautschnig <1144736+tautschnig@users.noreply.github.com>
Pipe protocols allow for some rather magical things regarding types. For example, consider this protocol:
Furthermore,
start
could be polymorphic itself and go to different instances ofwait_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:
The text was updated successfully, but these errors were encountered: