That test is only sufficient if the zeroth elements in the two slices are at the same address, which is often not true: https://play.golang.org/p/TH53Pxt5Do
Two slices sharing an array will, however, share their last element. Here is a better test, but this is pretty magical stuff: https://play.golang.org/p/SZgpCh9D-l Note that it cannot tell whether the elements actually overlap, but you can do that too if you work a little harder - again, capacity is the key. I leave that as an exercise. All that aside, copying a slice to itself is not a no-op computationally (it will execute the copy) but the slice will not be modified. -rob On Thu, Sep 7, 2017 at 5:41 PM, <djad...@gmail.com> wrote: > Hi, > Just check if backing array are same before copying: > https://play.golang.org/p/MSqs-jRkSO > > > On Thursday, September 7, 2017 at 8:54:16 AM UTC+3, Deepak Jois wrote: >> >> Hi >> >> Pls look at this code: https://play.golang.org/p/QfQOo1iyp4 >> >> I am copying a slice over itself. How does it work internally? Does >> the copy operation optimise for this, and not perform any copying in >> this case? >> >> I have to deal with a situation where I get a slice reference back >> from a function, and it is possible that it points to the same slice >> that I am trying to copy it into. It would be nice if the copy >> operation in that case is a no-op, but I don’t want to assume that is >> the case. >> >> Deepak > > -- > 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.
