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:

a.b=

but not for getters (they're unary). I don't think using get and set is much better:

a get b
a set b

// or

a.get b
a.set b

Using :: has been suggested before, and it seems to work pretty well:

a::b // getter
a::b= // setter
2::+
map::[]
map::[]=

The only thing left would be unary -. Maybe:

(2::unary -)

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.
   list.map(map.operator[]); // list of values from range of map.

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.
One reason is that it is a burden to write a correct type for hand-closurized code.
Either you have to guess the type, which may be (or become) inconsistent, or give up on types completely.

If I write (T1 b) => a+b
then I am imposing two type checks, one for T1 and another at the entry to operator+(T2 b).
It may have been my intention to write the same type but there is no mechanism to ensure they stay identical.

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

   a.get x
   a.set x

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.

Set owner to @gbracha.
Added this to the Later milestone.
Added Accepted label.

Removed this from the Later milestone.
Added Oldschool-Milestone-Later label.

Removed Oldschool-Milestone-Later label.