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 would obviate append(slice, 

[a, b, c, d] = [a, b] ++ []T{c, d}  // append(slice, ...elem)

And so now, perhaps, the reasoning behind + for string but not slice in go 
is clearer: To the go designers variadic function types combined with ... 
suffixed final slice arguments may have been preferable to operators but + 
for strings an exception due to precedent. It would seem less whimsical, or 
reliant on "ambiguity" type arguments, if such design rationales were 
documented somewhere.

To the go designers and implementers - thank you for a great tool.

On Saturday, September 17, 2016 at 10:44:14 AM UTC+1, parais...@gmail.com 
> 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 ? why 
> not using minus too for slices ? or multiply if my slice represents a 
> vector ? some languages handle that with operator overloading in user land, 
> Go just doesn't allow that. Adding more semantics to the plus operator 
> would be against the goals of the language IMHO.  
> Le samedi 17 septembre 2016 04:31:52 UTC+2, oyi...@gmail.com a écrit :
>> 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...) and append([]T, ...T) can stay as is but who needs it when 
>> you have []T ++ []T{...T}
>> On Saturday, September 17, 2016 at 12:31:31 AM UTC+1, parais...@gmail.com 
>> wrote:
>>> 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 
>>> understand why they were made. Go is only sophisticated in the way it 
>>> handles concurrency. 
>>> Le vendredi 16 septembre 2016 19:11:17 UTC+2, oyi...@gmail.com a écrit :
>>>> 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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to