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. Damian
