A slice shares enough properties with string to make + intuitive.
[a, b, y, z] = [a, b] + [y, z] // make() and copy()
To me the ++ operator (and +=) operator for slices are intuitive too.
[a, b, c, d] = [a, b] ++ [c, d] // append(slice, slice...)
An operator and composite literal combined wou
Context enables homonyms in spoken languages and overloaded or polymorphic
notation in mathematics. Types do the same in programming languages. The
rationale for + over join() or cat() for string is equally applicable to
slices. a ++ b wouldn't be an unreasonable replacement for append(a, b...)
The semantics of + and append() preclude a "data aliasing" ambiguity.
Consider:
c = a + b
and
c = append(a, b...)
On Friday, September 16, 2016 at 9:14:45 PM UTC+1, Thomas Bushnell, BSG
wrote:
>
> The values of the summation are indeed unambiguous, but the data aliasing
> properties are n
Thank you both.
To Ian: but a slice is not a matrix or a list.
To Axel: append() and copy() compliment indexing and slicing well enough.
It would be a shame if ambiguity is indeed the reason. We've accepted 1 + 1
as numeric addition and "a" + "b" as string concatenation. For a slice,
perceived
I have not been able to find an explanation. Does anyone care to explain or
point to relevant documentation?
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to gola
