The current Bytes and Runes method are a general type safety hole, since they permit changing the value of an unexported field. We should do this.

Is there a Value.Runes method?

@go101 apparently not! 😅

I was just riffing on #24746, but I'm not sure why @dsnet mentioned it there...

Updated proposal to remove references to the nonexistent Runes method.

To avoid breaking compatibility, maybe let the Bytes method return a deep copy of bytes is better.

Aha, sorry, then it still breaks the compatibility.

Remove Value.Bytes, making it accessible only to Go 1 code.

How would that work, given that it's always possible to access the Bytes method via reflection? Is it possible for reflect code to know whether it's being called by Go 1 or Go 2 code?

Relax reflect.Copy, reflect.Append, and reflect.AppendSlice to allow the source argument (but not the destination) to be obtained through unexported fields, provided that the element type of the slice does not contain any pointers or interfaces.

I suppose that Append and AppendSlice would also have to slightly alter semantics if the source was obtained through an unexported field - it would always need to copy the result, rather than using extra capacity when available.

Users could replace a call to Bytes on an exported field of known element type with a call to Interface and a type-assertion (https://play.golang.org/p/9LJIDW7ftZx).

That won't work if the slice is a named type with underlying type []byte which is currently allowed by Bytes. (https://play.golang.org/p/QbdhYJMZ_8u)

The workaround is possible, but a bit more awkward and with some performance implications. https://play.golang.org/p/JWXNzh238Ju

How would that work, given that it's always possible to access the Bytes method via reflection? Is it possible for reflect code to know whether it's being called by Go 1 or Go 2 code?

Good question! That could happen at the point where the Value is packed into an interface: if that point is in Go 1 code, then the concrete type indicated in the interface value would include the Bytes method, and otherwise it would not.

That could happen at the point where the Value is packed into an interface: if that point is in Go 1 code, then the concrete type indicated in the interface value would include the Bytes method, and otherwise it would not.

I'm not sure I can see how that could work. AFAICS it means that reflect.TypeOf(reflect.Value{}) would have different values throughout the system, breaking one of the fundamental reflect invariants.
Also:

• the Value might never be explicitly packed into an interface. https://play.golang.org/p/9USK58xRZah
• the Value is actually packed into an interface inside the reflect package (during the return from the Interface method), and that's always inside Go 2 code, so the heuristic would have to be more specific than that, I think. You could special-case reflect.Interface, but that wouldn't cover the fact that the Interface method could be assigned to function value.

I suspect that in this particular case, doing a Go 1/2 split is quite hard.

I wonder: would it be so bad if Bytes made a copy of the slice when the value isn't Interface-able, perhaps combined with a runtime warning that could be enabled to flag when this happens?