notes to hit on a potential RFC #27
Description
.@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.