bytes, strings: add Clone

[icholy]

Working directly with []byte is very common and needing to copy it comes up fairly often. A Clone helper would be nice to have.

What did you expect to see?

dup := bytes.Clone(data)

What did you see instead?

dup := make([]byte, len(data))
copy(dup, data)

Implementation

package bytes

// Clone returns a copy of b
func Clone(b []byte) []byte {
  b2 := make([]byte, len(b))
  copy(b2, b)
  return b2
}

[bradfitz]

If accepted, Clone would probably be a more clear and matching name:

go1.txt:pkg html/template, method (*Template) Clone() (*Template, error)
go1.txt:pkg text/template, method (*Template) Clone() (*Template, error)
go1.8.txt:pkg crypto/tls, method (*Config) Clone() *Config
go1.13.txt:pkg net/http, method (Header) Clone() Header
go1.13.txt:pkg net/http, method (*Transport) Clone() *Transport
go1.13.txt:pkg net/http, method (*Request) Clone(context.Context) *Request

Copy makes it sounds like the built-in copy.

[jimmyfrasche]

Would this be a better fit for the likely generic slices package, so it could work on any []T?

[ulikunitz]

There is already a generic way to do it in one line.

b2 := append([]byte(nil), b...)

This approach is even faster because the allocated slice will not be initialized to zero values.

[icholy]

@ulikunitz I think that's an argument for adding a bytes.Copy function. Most of the code I've seen uses the two step approach. A helper would probably result in more people using the faster approach.

[martisch]

@ulikunitz

b2 := append([]byte(nil), b...)

This approach is even faster because the allocated slice will not be initialized to zero values.

For simple cases like in the example code at the thread start (no complex computation in length argument) make + copy should be faster than append since go1.15: #26252 (comment) as the go compiler avoids the zero value intialization there too.

[DeedleFake]

I think that even with append() being available for this, a simple generic Clone() or Copy() function in a slices package that basically just wraps that would be worth it simply to avoid the need to match the type manually:

b2 := append([]byte(nil), b...)
// vs.
b2 := slices.Clone(b)

[zigo101]

@DeedleFake
Yout don't need to write out the type []byte manually in an append call. Just do append(b[:0:0], b...). So personally, I think the append call is more graceful the slices.Clone call. The only drawback of append calls is that they might zero some redundant elements so they are often a little slower than make+copy calls since Go toolchain 1.15 (as mentioned by @martisch above).

[ericlagergren]

Just do append(b[:0:0], b...).

While that works, I think it's definitely confusing, especially if somebody else owns b (like io.Reader). I'd personally object to that in a code review.

That said, does this proposal also require strings.Copy? IIRC there has been some confusion both in the gophers slack and in GitHub issues about whether string([]byte(s)) will always make a copy of s.

[icholy]

@ericlagergren strings are immutable, there's no need to copy them.

[ericlagergren]

There is need to copy them. For example:

s := "big long string"
x := s[:3]
// no more uses of s, but x is kept
// alive for a long time, keeping the
// entirety of s in memory until x is
// collected because the GC does not
// collect partial objects. 

This has implications for things like string interning.

[zigo101]

In Go programming, there are many cases in which a small piece of a memory block is active prevents the whole memory block being released, not limited to slices and strings.

[josharian]

See #25834.

[earthboundkid]

The append trick works well, but you have to have read the Go slices tricks wiki page to know to do it. If generics add a slices package, it would make sense to have slices.Copy[T any](s []T) []T as a function if only because it would have better discoverability for new gophers. That said, I don't think it makes any sense to add bytes.Copy today because we're so close to generics and the append trick works already.