Method chaining/cascading

[jdlib]

Method chaining and fluent interfaces have been getting popular the last years since they allow to write condensed code like:

x.f().g().h()

instead of

x.f()
x.g()
x.h()

Usually this is implemented by returning this from the called method.

Now V advises against this solution for good reasons, as discussed in the docs.

So here is my idea:
Another way to achieve the desired effect would be to introduce a cascading operator, e.g. .. as Dart does.

x.f()..g()..h()

This is just simple syntactic sugar and would not require the cascaded functions to return anything. See https://en.wikipedia.org/wiki/Method_cascading for detailed discussion.

[hungrybluedev]

Since V distinguishes between mut and default non-mutable variables, how would the syntax distinguish between them?

For immutable objects, chaining seems alright. Everything returns a transformed version of the original object, so that makes sense.

For mutable objects, how would you denote that? How would you enforce heap only or stack only requirements?

[jdlib]

As mentioned in my post the cascading operator is just syntactic sugar (is resolved in a preprocessing step):

x = ...
x.f()..g()..h()

is just short for

x = ...
x.f()
x.g()
y.h()

and of course any of these calls may not be allowed due to mutability reasons and should be rejected by the compiler.