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

notes to hit on a potential RFC #27

Open
yoshuawuyts opened this issue Jun 14, 2023 · 1 comment
Open

notes to hit on a potential RFC #27

yoshuawuyts opened this issue Jun 14, 2023 · 1 comment

Comments

@yoshuawuyts
Copy link
Member

.@joshtriplett provided a useful outline of which points we may want to hit on a potential RFC:

So, rough sketch off the top of my head:

  • There's this mechanism for polymorphic effects / effect generics (pick one term and stick with it). There's a lot of literature on it that we've looked at, but we'll present enough detail in this proposal to evaluate without being familiar with that literature.
  • Some examples of things we could potentially treat as effects include async, const, ...
  • Here's a rough summary of what it would mean for something to be polymorphic over const. Here's a rough summary of what it would mean to be polymorphic over async.
  • When you look at polymorphic effects, they look at first like they might be a separate mechanism from polymorphic types. And the literature suggests you need might need an effect resolver separate from your handling of type generics. But here's a desugaring that demonstrates they are equivalent, given our support for const generics. And (if at all possible) here's a link to someone else in the literature similarly showing that they're equivalent in power and don't necessarily need to be handled separately. OK, now that you've seen that, we'll never bring this complicated desugaring up again.
  • Here's a rough idea of syntax we could hypothetically use; this isn't a final proposal.
  • Here's an idea of what it means for a trait to be effect-polymorphic, and how that interacts with the functions within it potentially being effect-polymorphic. Here's how a function within it doesn't have to be effect-polymorphic.

I'm pasting it here because it seems like a useful starting point for a potential RFC - and I didn't want to dig through DMs to dig it back up. Pasted here with permission.

@clarfonthey
Copy link

Related to this, is there a working draft of an RFC somewhere or is that something that could maybe be added to this repository? Since I feel like it would be useful even if it were just putting the different bullet points like these into the relevant sections of it.

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

No branches or pull requests

2 participants