Setter functions, parameterized setters.

[lrhn]

Probably a crazy idea, but the []= operator is very useful because it allows a parameterized setter. It only has one parameter, though.

So, what if you could declare parameterized setters with any parameter list.

class Canvas {
  Color pixelColor(int x, int y) => grid[x][y];
  pixelColor(int x, int) set (Color color) {
    grid[x][y] = color;
  }
}

This is a parameterized setter.
It's invoked like canvas.pixelColor(3, 4) = .red;

As a setter, its return value is always void, which you can write or not.

Its member name is pixelColor= and its function type is void Function(Color, int, int), when it matters for overriding. (The value goes first as a required parameter, to allow subclasses to override with a function type that has more optional parameters. Alternatively, the function type could be the curried void Function(Color) Function(int, int). That could actually be easier to reason about, but a noSuchMethod invocation would flatten the arguments in the parameter list, so might as well be consistent. And, annoyingly, an Invocation for an invalid operator[]= has the arguments in the opposite order.)

You still cannot tear off a setter. Doing canvas.pixelColor will give you the function. If there was no such function, you still didn't write the name pixelColor=, so you won't get the setter. (So it doesn't matter whether it's function type is curried or not, it never exists less than fully applied. Except perhaps for dart:mirrors, which long ago stopped supporting new features.)

The parameterized setter can be generic too, all parameters can refer to the type parameters.

If the same scope has a normal function with compatible parameters, you can do composite assignments:
canvas.pixelColor(3, 4) *= dimming ; behaves like canvas.pixelColor(3, 4) = canvas.pixelColor(3, 4) * dimming;, which must then be valid invocations of both (modulo the usual "only evaluated once" clauses). Just like operator[].

Alternatively, maybe it could extend the current setter syntax, and look "less weird" with the two parameter lists in one declaration:

class Canvas {
  set pixelColor(Color color, int x, int y) {
    grid[x][y] = color;
  }
}

which is like a setter, only with more parameters. There has to be at least one required positional parameter for the value.
If there is only one parameter, it's just a normal setter, the dual of a getter.
If you have more than that one parameter, the rest become the parameters of a parameterized setter,
which must be invoked using (...)=, the dual of a function call.
(So set pixelColor(Color color, [int x = 0, int y = 0]) { ... } can be invoked as .pixelColor() = .red, but not .pixelColor = red. Even if all the parameters are optional, it's not an unparameterized setter, it's a parameterized setter which can be called with zero arguments.)

That said, I think the "two parameter lists" syntax is more readable, because it looks more like how it's invoked.

Related issues

• Allow multiple arguments to index operators #2534 "Allow multiple arguments to index operators": Allows more parameters for one setter, operator[] .
  Is a little hampered by the parameter order (value last). In the thread I suggested

  T operator[int x, int y] => ...
   void operator [int x, int y]=(T value) => ...

  as alternative. Looks more like how it's invoked, so actually a nice syntax.
  Maybe we could allow you to write operator[]=(index, value) as operator[](index) set (value) ,
  which can then generalize cleanly to multiple parameters if we want it.)
• I've suggested (can't find the issue right now) a combined getter/setter syntax to avoid
  repeating the name and type (and wondering where to write a comment), like

  int _foo = 0;
  /// The foo. If changed, will notify of changes.
  int foo {
    get => _foo;
    set(value) { if (value != _foo) _notifyChange(_foo = value); } 
  }

  this could generalize to functions ... somehow.

  Color pixelColor(int x, int y) <keyword here?> {
      get => grid[x][y]; 
      set(color) { grid[x][y] = color; }
  }

[ykmnkmi]

I like this version more

T operator[int x, [int? y]] => ...
void operator [int x, [int? y]]=(T value) => ...

object[1] = ...
object[1, 2] = ...

[lrhn]

Using operator[] only allows having one parameterized setter function. Using named functions allows one per name.

I guess you could have specialized getters returning objects with operator[]s, so o.foo[42, 42] = 84 works by having FooIndexedProperty get foo => FooIndexedProperty(this); on o, and then [42, 42] = 84 is an invocation on FooIndexedProperty, which forwards back to the o object.

I think it's more direct to declare the functionality in the class itself, which o.foo(42, 42) = 84 would allow.

But then we could introduce a syntax for named "indexed property declarations" by allowing a name in front of [,
(I'd say "instead of operator", but operator is a valid member name, so probably need to keep the operator
with the name):

 int operator foo[int a, int b] {
     get() => this._something[a][b];
     set(value) => this._something[a][b] = value; 
 }

or without unified property declarations:

 int operator foo[int a, int b] => this._something[a][b];
 void operator foo[int a, int b]= (int value) { this._something[a][b] = value; }

You can't tear off o.foo, it's not a function. It must be indexed before it exists, so o.foo[42, 42] is a thing,
but it's a getter, so you just gets its value. Still can't tear it off.
And can be generic, so operator foo<T>[T a, T b] => .... It's a new kind of parameter list. It could only works as an instance member (like other operators), but the named version can be allowed everywhere (if using operator in a top-level declaration is not a syntax issue.)

The members name will be foo and foo=, the function signatures here would be int Function(int, int) with kind "getter"
and void Function(int /* value */) Function(int, int) with kind "setter" (only matters for overriding).

It's not a bad syntax. If we need new syntax anyway, we could do this instead.

If we generalize this to operator[], then there is a slight chance of syntax confusion, but nothing actually ambiguous:

  void operator[]=(int x) {...} // new syntax, `int x` is value of zero-parameter setter.
  void operator[]=(int x, int y) {...} // existing syntax, `int x` is index, `int y` is value.

Those are "very adjacent" in syntax space, and are read completely differently.
Since the number of parameters in that position is fixed (one if it's a new-syntax value, two if it's an old-syntax index set), it's not ambiguous, and if we have a lint to prefer the new syntax, you'd be told if you write the old one by accident.

Not bad.

(But it does mean we now have two ways to write parameter lists and two ways to invoke functions. When should you use
foo[a, b] instead of foo(a, b)? The style guide would like to know.)