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

Self-documenting offer!() and choose!() #101

Open
yaymukund opened this issue Apr 19, 2021 · 3 comments
Open

Self-documenting offer!() and choose!() #101

yaymukund opened this issue Apr 19, 2021 · 3 comments
Labels
enhancement New feature or request

Comments

@yaymukund
Copy link
Contributor

Could we do something like:

offer!(in chan {
    End => break chan.close(),
    Push => {
        // push a value
    }
})?;

End and Push would reduce to enums:

enum Choice {
    End,
    Push
}

offer!(in chan {
    Choice::End => ...,
    Choice::Push => ...,
})?;
@yaymukund yaymukund added the enhancement New feature or request label Apr 19, 2021
@sdleffler
Copy link
Contributor

I've been hoping for something like this for a while; unfortunately, there are some nasty reasons this is not currently doable. Right now, the numeric indices are used to index a trait as const generics (trait Case<const N: usize> in Vesta.) I have some ideas on how we could potentially get around this with overly clever use of macros but they can't currently be anything other than usize or something that becomes usize because of how early in compilation they have to be used.

@sdleffler
Copy link
Contributor

Also... just realized you're probably looking at main while writing this. :D The carrier-type branch is the current state of enhancements for offer!(). main doesn't use Vesta yet.

@yaymukund
Copy link
Contributor Author

yaymukund commented Oct 7, 2021

This isn't presently possible because at macro expansion time, there's no way to go from Push to Choice::Push because name resolution happens after macro expansion.

If you can access the enum, then you can turn that into an integer using a sweet hack™ which would involve having a module by the same name (so it gets imported automatically with the Choice enum) that contains an enum that maps to the integer index. I probably messed up some part of that explanation, but hopefully it offers (eyyy) a starting point.

Both of these issues could be solved a lot nicer with const generic enums, but so could a lot of dialectic.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants