Add Dart's cascade/chaining operator `..`

Here’s a request that is based on #4049 but with a simpler scope that eschews the complexity from that request: add a .. operator that desugars to reusing the instance at the start of the chain.

value myLongValueName =
  construction()
  ..descriptivelyNamedMethodFoo(1, 2)
  ..otherMethodBar{ myFirstParam = aValue; thisIsDifferent = somethingElse; }
  ..heresAnotherBaz();

would desugar to

value myLongValueName = construction();
myLongValueName.descriptivelyNamedMethodFoo(1, 2);
myLongValueName.otherMethodBar{ myFirstParam = aValue; thisIsDifferent = somethingElse; };
myLongValueName.heresAnotherBaz();

It can be argued that the benefit of readability afforded by fluency isn’t worth tailoring APIs for it, especially as Ceylon isn’t leaning toward it in the first place, but surely a simple .. operator with a well-specified and understandable behavior could do the trick, even if it’s not associated with an interface (I reckon that Gavin has changed his mind on more fundamental tenets of Ceylon than code sugar rules).

[ncorai]

Its value is that it solves a design conundrum: currently, a method that returns the instance on which it is invoked can indicate two things:

• the object is immutable and returns a copy with the state altered, or
• the API is fluent and the same instance is returned in an altered state.

This dichotomous approach muddles the clarity of an API, and forces a choice on the designer. The cascade operator resolves that ambiguity, since you don’t need fluent APIs anymore. Fluency becomes a choice for the invoker, provided by the compiler for free.

I should note that there are other use cases for fluent APIs than Builder patterns. Recently, I was confronted with IO streams that would force me to repeatedly write the variable name, needlessly cluttering the method body.

[ncorai]

Because of the overlap with the range operator, I don’t feel 100% comfortable with adding this I’ll admit, so I won’t advocate it any further. As I realized after opening the issue, it would substitute the .. operator ambiguity to the return value ambiguity, so not a clear win. I’ll close this issue and you guys can move the with operator discussion to its own issue if need be.