-
Notifications
You must be signed in to change notification settings - Fork 1.1k
CC: Better End-User Syntax for Declaring and Mentioning Capture Variables #22490
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
Comments
One idea that came up in offline discussions is reusing the context bound notation for declaring a capture variable: def foo[A:CapSet] = ??? with the aim that this notation internally desugars into the current encoding def foo[A >: CapSet <: CapSet^] = ??? This will require special treatment of How should this extend to declarations of capture variables which are sub-/supercaptures of def foo[A: CapSet, B <: A : CapSet, C >: B <: A : CapSet] = ??? We'd expect this to desugar into the existing scheme def foo[A >: CapSet <: CapSet^, B >: CapSet <: A, C >: B <: A] = ??? while making sure that omitted lower (upper) bounds are That seems still a bit verbose, should we instead aim for def foo[A: CapSet, B <: A, C >: B <: A] = ??? I.e., just by being subtyping-related to the declared |
Just for reference, if the example were written in Rust with lifetimes this is how it would look like: // assuming a lifetime 'bb was predeclared,
// since we cannot mention lifetime of a variable directly
let b: &'bb Bar = ???
fn capturePolyDef<'a,
'b: 'a,
'c: 'b,
'd: 'c,
'e: 'd,
'f: 'a + 'bb,
'x: 'f + 'd,
'y, // lower bound constraints must come in `where` clauses
'z>()
where
'y: 'f + 'a + 'bb,
'f: 'y,
'z: 'bb + 'y,
'b: 'z,
{
todo!()
} Notably the |
At one of the recent LAMP meetings, we gravitated towards this form: def foo[A: CapSet, B <: A : CapSet, C >: B <: A : CapSet] = ??? But then we switch from "too many hats" to "too many def foo[A: CapSet, B <: CapSet^{A,x,y,z} : CapSet] = ??? which seems not the most ideal. Regarding
we can build on the proposed mechanism for |
Right now, the syntax for explicit capture polymorphism is quite noisy and irregular:
For example:
There are too many hats
^
and it's not always clear when they are needed, e.g., all the type variables in the example are capture variables, but onlyA
's declaration carries the^
(which is a shorthand forA >: CapSet <: CapSet^
.There's two ways to write down a capture variable's bounds, e.g.,
E
's upper bound isCapSet^{D^}
but could equivalently be written as justD
.Lots of
CapSet
mentions everywhere, which seems a bit clunky to express simple subset relationships.TODO: how does/will Capybara affect capture set notations?
Let's use this issue to track ideas for making the notations more palatable.
The text was updated successfully, but these errors were encountered: