Comparing slices themselves, not the values in the slice?

<p>I&#39;m trying to compare to slices to see if they&#39;re the same .. slice. <em>Not the values</em> within the slice, but if they&#39;re the same slice. Upon trying <code>a == b</code> i found out Go doesn&#39;t allow that.</p> <p>Eg: My goal is something like this code:</p> <pre><code>a := []int{1,2} b := a c := []int{1,2} if a == b { // I know they&#39;re the same slice, do stuff. } </code></pre> <p>I would expect <code>a == c</code> to fail, because they&#39;re different slices entirely, even though they have the same values.</p> <p>Thoughts?</p> <hr/>**评论：**<br/><br/>014a: <pre><pre><code>reflect.ValueOf(a).Pointer() </code></pre> <p>Might work. </p> <p>Its a weird request though. Not that your use-case is weird, but that its something &#34;weird&#34; in the context of Go. Slices are views into arrays, so something like:</p> <pre><code>a := []int{1,2} a1 := a[:] b := a b1 := b[:] </code></pre> <p>Never actually &#34;do&#34; anything. There&#39;s no copying. There&#39;s no new data. All of those assigned variables point to the exact same data in memory.</p></pre>TheMerovius: <pre><pre><code>len(a) == len(b) &amp;&amp; (len(a) == 0 || &amp;a[0] == &amp;b[0]) </code></pre> <p>Note, that this will consider all length-zero slices to be equivalent, which makes sense, given what <a href="https://golang.org/ref/spec#Size_and_alignment_guarantees" rel="nofollow">the spec has to say</a> about that:</p> <blockquote> <p>Two distinct zero-size variables may have the same address in memory.</p> </blockquote> <p>(i.e. the address in a zero-length slice may or may not be the same)</p></pre>lhxtx: <pre><p><code>reflect.DeepEqual</code>?</p></pre>sOundsoFpErsistence: <pre><p>That compares values, does it not?</p></pre>singron: <pre><p>You can compare their lengths and a pointer to their elements. I.e.</p> <pre><code>len(a) == len(b) &amp;&amp; (len(a) == 0 || &amp;a[0] == &amp;b[0]) </code></pre> <p>This assumes that 0 length slices are identical, but that might not be true if they have unused non-0 capacity. It probably doesn&#39;t matter since <code>append</code> can always do a reallocation, so you probably arent interested in the identity 0 length slices.</p></pre>jerf: <pre><p>For fun, <a href="https://play.golang.org/p/r7Q0M3I1l5M" rel="nofollow">see this playground entry</a>.</p> <p>Even so, I wouldn&#39;t use this, because while it establishes that the two slices in question are <em>currently</em> pointing to the exact same thing, they&#39;re still not identically the same, like they would be in some languages. Notice in this <a href="https://play.golang.org/p/q_QiYTejlog" rel="nofollow">very similar code</a> that when I pass the same slice in to a function twice, and append to one parameter but not the other, that the slices are now different, and have different pointers in the function. Slices don&#39;t have the kind of identity I suspect you are looking for, because the <a href="https://golang.org/pkg/reflect/#SliceHeader" rel="nofollow">three fields of a slice</a> are copied by value when they are passed into a function.</p> <p>If you want it, you&#39;ll have to impose it yourself:</p> <pre><code>type MySlice struct { S []int } </code></pre> <p>Now <code>&amp;MySlice</code> can serve as an identity cleanly. (Technically you can <code>type MySlice *[]int</code>, and then that pointer can be the identity, but while I&#39;m not sure I&#39;m ready to call that &#34;Un-Go-ic&#34;, it would make a lot more future readers of your code go &#34;Bwuh?&#34; in a way that the previous type will not.)</p> <p>Even so, I would <em>still</em> suspect you of playing games with Go that you probably shouldn&#39;t. Perhaps you should give us a hint of why you want to do this?</p></pre>