Larry mused:

>   �...@a.mung
> the .mung could return
>    A) a modified @a (treat @a as mutable)
>    B) a new array (treat @a as immutable)
>    C) a remapped array whose elements refer back to @a's elements
> Currently .rotate is defined as A, but I could easily switch it to B,

I, for one, would vastly prefer to see the majority of (or even all)
container methods being non-mutating (with sugary shortcuts for the most
common mutators, if necessary).

A major advantage of having both .= and . in the language is that they
make it easy to see when something is (and isn't!) being altered in-place.
The fewer special-case "it-uses-plain-dot-but-it's-actually-a-mutator"
exceptions we have, the better.

In fact, I would even be happy with requiring @a.=push and @a.=shift, if
it meant that there were *no* special cases. One extra character is a
small price to pay for perfect SWIM (and not just "Say What I Mean",
the real benefit is the other SWIM: "See What I Meant").

Of course, this assumes that @a.=shift, @a.=push, etc. aren't actually
implemented with a copy-modifier-and-replace, but are optimized to
in-place mutators, under the hood.


Reply via email to