[go-nuts] Re: Why + and += operators for string but not slices?

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

[go-nuts] Re: Why + and += operators for string but not slices?

On Friday, September 16, 2016 at 11:11:17 AM UTC-6, oyi...@gmail.com wrote: > > I have not been able to find an explanation. Does anyone care to explain > or point to relevant documentation? > One data point: I'd expect slice + slice to create a new object, that is, a new backing array. I'd

[go-nuts] Re: Why + and += operators for string but not slices?

The more contextual a PL's semantics is the harder it is to make sense of a program written in that PL (the inverse is also true, that's why we don't program lining zeros and ones ) ... The problem with what you are asking is why yet another special case for slices ? why not one for channels ?

Re: [go-nuts] Re: Why + and += operators for string but not slices?

On 17 Sep 2016 12:31 p.m., wrote: > > 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. 1+1 give

[go-nuts] Re: Why + and += operators for string but not slices?

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

[go-nuts] Re: Why + and += operators for string but not slices?

Because Go creators have a strong opinion about what + means. I would argue the languages that engage into these sort of things especially those who allow operator overloading are antithetic to Go goals, but that's an opinion., I didn't create Go, I don't agree with all its design choices but

Re: [go-nuts] Re: Why + and += operators for string but not slices?

The thread already shows several alternative interpretations which are different from that. Go tries to avoid constructions that require careful specification of that sort. Append already causes enough confusion, but that's important enough that dropping it would be a loss. + for slices is only

Re: [go-nuts] Re: Why + and += operators for string but not slices?

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

Re: [go-nuts] Re: Why + and += operators for string but not slices?

The values of the summation are indeed unambiguous, but the data aliasing properties are not. On Fri, Sep 16, 2016, 12:58 PM wrote: > 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

[go-nuts] Re: Why + and += operators for string but not slices?

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,