Thanks Nate,
--
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.
On Wednesday, 16 August 2017 05:16:45 UTC+2, Nate Finch wrote:
>
> This is an unfortunate side effect of using ... (a variadic) in append.
> Zero is a valid number of arguments to pass to it.
>
>>
>>
>> But append is not a normal function, it is an intrinsic, so the compiler
could implement a
Sometimes, I use:
a := []int{ 1, 2, 3 }
b : = append([]int(nil), a...)
to copy a slice.
On Wednesday, August 16, 2017 at 12:31:13 PM UTC-7, Nate Finch wrote:
>
> Wrote it up as an issue: https://github.com/golang/go/issues/21482
>
> and I agree that using append to assign to a different variable
Wrote it up as an issue: https://github.com/golang/go/issues/21482
and I agree that using append to assign to a different variable than the
one in the append call is almost always going cause surprising behavior
but it's less clearly a mistake than append with only a single argument.
On Wed
Agreed, append with only one argument doesn't look good and should be
vetted.
As a superset of this problem, any use of
*a* = append(*b*, *c*)
with *b* != *a* (i.e. not assigning back to the same slice variable)
looks either broken or cryptic me.
This holds whether *c* is zero or one or more v
This is an unfortunate side effect of using ... (a variadic) in append.
Zero is a valid number of arguments to pass to it.
However, I think this is a 100% valid thing to put into go vet. There's
never a time when someone writes this code on purpose instead of just
writing buf = byteArray.
