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

[oyi812]

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

[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 
wrote:
>
> 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.

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

[johnroth1]

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 also expect += to concatenate using the same backing 
array for the result object. That's the way Python does it, and I've got a 
bit of Python background.

That said, though, I'd wonder what would happen for a slice of some complex 
object. To take an extreme example, what would adding slices of maps or 
channels do?

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

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

[paraiso . marc]

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.

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

[Jesse McNelis]

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 you a new number that doesn't modify the original numbers being
added.
This is the expected way addition works.

In Go this also works for strings, "a"+"b" gives you "ab" and the original
strings are unmodified.

For slices this is different, two slices can refer to the same backing
array so slice1 + slice2 could either allocate a new slice and copy both
slices in to it, or it could modify slice1 by appending slice2.

If slice1 and slice2 refer to the same backing array, their addition could
change both of the original values, this addition can also effect slice3
that happens to also reference the same backing array.

append() isn't addition because of these properties.

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

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

[oyi812]

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.

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

[paraiso . marc]

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.

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

['Thomas Bushnell, BSG' via golang-nuts]

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 syntactic sugar.

Thomas

On Fri, Sep 16, 2016 at 3:09 PM  wrote:

> 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 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 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 as a window on a string of elements, concatenation is
> unambiguous. [a, b, c] + [x, y, z] = [a, b, y, z]
>
>
>
>
>
>
>
> On Friday, September 16, 2016 at 6:11:17 PM UTC+1, oyi...@gmail.com wrote:
>
> 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...@googlegroups.com.
>
>
> For more options, visit https://groups.google.com/d/optout.
>
> --
> 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.
>

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

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

[oyi812]

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 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 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 as a window on a string of elements, concatenation is 
>> unambiguous. [a, b, c] + [x, y, z] = [a, b, y, z]
>>
>>
>>
>>
>>
>>
>>
>> On Friday, September 16, 2016 at 6:11:17 PM UTC+1, oyi...@gmail.com 
>> wrote:
>>>
>>> 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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

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

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

['Thomas Bushnell, BSG' via golang-nuts]

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 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 as a window on a string of elements, concatenation is
> unambiguous. [a, b, c] + [x, y, z] = [a, b, y, z]
>
>
>
>
>
>
>
> On Friday, September 16, 2016 at 6:11:17 PM UTC+1, oyi...@gmail.com wrote:
>
> 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.
>

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

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

[oyi812]

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 as a window on a string of elements, concatenation is 
unambiguous. [a, b, c] + [x, y, z] = [a, b, y, z]







On Friday, September 16, 2016 at 6:11:17 PM UTC+1, oyi...@gmail.com wrote:
>
> 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.