It’s by design, though I understand the concern. From a design perspective, I like getting a distinct slice out the other end, without having to wonder whether I’ve mutated my original slice. It’s more stateless, so to speak.
Fwiw, slices are inexpensive by design. The elements themselves are not copied. Allocating a new slice is really a small ‘struct’ which serves as a pointer to the underlying array: http://blog.golang.org/go-slices-usage-and-internals
(Gen’ing pointers is supported, which mitigates the potential for allocation.)
It is true that chained operations will be multiple iterations. Whether it will net out to more iterations than otherwise depends on the use.
I’d be interested to see if someone can come up with a pattern where the operations themselves are composed, with a ’.Results()’ method that can intelligently (lazily?) minimize iterations. That’d be impressive.
Fwiw, slices are inexpensive by design. The elements themselves are not copied. Allocating a new slice is really a small ‘struct’ which serves as a pointer to the underlying array: http://blog.golang.org/go-slices-usage-and-internals
(Gen’ing pointers is supported, which mitigates the potential for allocation.)
It is true that chained operations will be multiple iterations. Whether it will net out to more iterations than otherwise depends on the use.
I’d be interested to see if someone can come up with a pattern where the operations themselves are composed, with a ’.Results()’ method that can intelligently (lazily?) minimize iterations. That’d be impressive.