Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Make binary operators closurizable. #5879
Make it possible to extract a bound operator, just as extracting a method works.
Haskel-style: (2*) omitting an operand makes it a closure. We don't need to support (*2) as well, it's just not the Dart way. I think parsing will be acceptable - it'll just have to detect some cases that are now an error.
Dot-style: 2.* simply putting a '.' before an operator name will treat it like a named access. It's not otherwise valid syntax. For index/indexSet it will be just map. and map.= .
I prefer the former, but that's just because the latter is ugly.
This comment was originally written by @seaneagan
wanting to closurize getters and setters is probably equally as common. The second syntax above might work for setters:
but not for getters (they're unary). I don't think using get and set is much better:
a get b
Using :: has been suggested before, and it seems to work pretty well:
a::b // getter
The only thing left would be unary -. Maybe:
I like the Haskel style, but I'm worried that there may be some syntactic issues. '<' is also used for parameterized types.
One way of avoiding unintended consequences is to use 'operator' like the declaration syntax, e.g.
var addTwo = 2.operator +;
list.map(map.containsKey); // list of true, false.
I'm sure you find these even more ugly than map., but there is a consistency with the declaration which might help newcomers to the language guess what is happening.
I think all kinds of instance methods should be closurizable.
If I write (T1 b) => a+b
I think closurization could be nicely uniform. If we say that the name of getters and setters is 'get x' and 'set x' (instead of 'x' and 'x=') the suggestion of
is completely regular with operators and methods named by an identifier.
I actually like the .operator+ notation, but I disqualified it because I don't think it'll work. "operator" is not a keyword, and it's a valid property name. I.e., the syntax "c.operator+(2)" is already valid and means something else.
The "::" notation is viable, and works on getters as well (unlike either of my suggestions pout).
Unary minus is a problem. If it's reasonably implemented, it will be a constant function, but then, it might not be used reasonably.