<p>I'm a little unsure what the most idiomatic way of dealing with destructive functions in Go is.</p>
<p>Let's say I have the following:</p>
<pre><code>func ShuffleA(slice *[]Card) {
// shuffling code here, unimportant for the issue at hand
}
func ShuffleB(slice []Card) []Card {
// shuffling code here, unimportant for the issue at hand
}
</code></pre>
<p><code>ShuffleA</code> is destructive, while <code>ShuffleB</code> is not.</p>
<p>The question is, which one is the more idiomatic to use in Go, and more importantly, if I have one, is there an idiomatic name for the other?</p>
<p>In <em>Scheme</em> destructive functions are suffixed with a <code>!</code>, so there you'd have <code>shuffle</code> and <code>shuffle!</code>, which gives a clear indicator as to what's destructive and what isn't. Now, I know Go isn't Scheme, and I'm not looking to compare them. I'm just asking in case other people are going to use my code; I don't want the functions to go against what they expect them to do.</p>
<hr/>**评论：**<br/><br/>Fwippy: <pre><p>I think the destructive version is more idiomatic.</p>
<p>If you wanted to provide both, I'd suggest</p>
<pre><code>func Shuffle(slice []Card){}
func Shuffled(slice []Card) []Card{}
</code></pre>
<p>(inspiration from python's <code>sort</code> and <code>sorted</code>).</p></pre>anotherdonald: <pre><p>I'm just a go beginner, but they have different uses, don't they? ShuffleA affects all data structures pointing at slice, while ShuffleB doesn't (assuming it just shuffles the contents of the array).</p>
<p>I don't remember having seen this mentioned in the context of naming, though.</p></pre>TheTimegazer: <pre><p>well A and B only affect slices of that particular type, the only real difference between them is that one destroys the original slice by modifying it; while the other returns a new slice, leaving the original untouched</p></pre>mcouturier: <pre><p>Everywhere in core I have seen the second way. Check append(), bytes.Replace, etc...</p></pre>ultra_brite: <pre><p>It doesn't matter, none is more idiomatic than the other. Suffixing a function with a ! is a matter of convention in Scheme. Go doesn't support ! in variable names.</p></pre>TheMerovius: <pre><p>When dealing with slices, it's pretty unidiomatic to use a pointer, but it still would be idiomatic to do a shuffle "destructively", so my answer is, neither, but instead</p>
<pre><code>func ShuffleC(slice []Card) {
// shuffling code here, unimportant for the issue at hand
}
</code></pre>
<p>Shuffling doesn't need to change a slice, just it's contents, so don't take a pointer. See, for example, all the <code>sort.Interface</code> implementations.</p>
<p>Only return a new slice, if what you want can not be done well in-place anyway. <code>string.Replace</code> is an example of something that <em>cant</em> be done in-place, so returning the new string is fine. Same for <code>bytes.Replace</code>: In general, the resulting slice will have a different lengths from the input, so the slice would need to be modified.</p>
<p>Another example of how to deal with this is <code>io.Reader.Read</code>. Strictly speaking it would need to modify the slice (because it only fills part of it). Instead, it does a completey different thing, which is to return an integer with the number of bytes filled.</p>
<p>Overall, there is no convention around any of this. I'd encourage you to lean on the destructive side, though, because that way you give the choice of whether or not to allocate to the user of your package. Go is not a functional language, so the compiler will do less work around optimizing out such allocations. But in the end, you should do what makes most sense for your API. The signature will mostly make it clear whether the function is destructive or not, otherwise the documentation should tell you.</p></pre>danredux: <pre><p>Mutate your arguments, it's more efficient.</p>
<p>The caller will copy anything it needs to keep.</p></pre>Nathanfenner: <pre><p>If you're only shuffling, and not changing the length of the slice or replacing it with a slice allocated elsewhere in memory, there is no reason to pass a pointer to the slice. Slices are just (data, length, capacity) tuples (in some order). If you modify the values it points to, the "original" slice (which is an exact, shallow copy of the original) would be modified.</p>
<p>For example:</p>
<pre><code>function Shuffle(slice []Card) {
for i := range slice {
j := rand.Intn(len(slice) - i) + i
slice[i], slice[j] = slice[j], slice[i]
}
}
</code></pre>
<p>will work as expected and modify the passed-in slice.</p>
<p>Pointers to maps, slices, and interfaces aren't used much (although for example if you want to modify the length of a passed in slice, you would need to pass a pointer to it).</p>
<p>I would say that usually, if the function is simple, such as shuffling, it doesn't really matter what you do. If someone doesn't want their slice modified, they can just copy it before calling.</p>
<p>If the function is complicated, and, for example, also returns some other value, then it is probably undesirable to modify the arguments if it would be surprising.</p></pre>NeverUse-YouPromised: <pre><p>Slices are reference types, kind of like hidden pointers. You don't need a pointer to a slice to be able to modify it within a function.</p></pre>tdewolff: <pre><p>You <em>do</em> need a pointer if you add or remove items</p></pre>
