runtime, strings, bytes: undo use of runtime as dumping ground for shared code

[josharian]

From CL 38693:

@martisch said:

I think it is not a good general direction that more and more code is shared between string and bytes by moving it into the runtime and that code seems actually not be used by the runtime.
Maybe a separate github discussion would be good about alternatives and moving the shared code out of the runtime and just e.g. importing the bytes package code into the string package

@randall77 replied:

This is a good question. We are starting to dump a lot of stuff in runtime that is really just "stuff that two other packages have to share". Perhaps a new internal package somewhere would be more appropriate.

This issue is to continue/resolve the discussion.

[rsc]

It would be good for neither bytes to depend on strings nor strings to depend on bytes. Everything depends on runtime so that's the dumping ground. If we want an internal package that both bytes and strings depend on, that seems OK.

[rsc]

Also, on March 30, "this issue is to continue/resolve the discussion." Should anyone else be in this discussion?

[rsc]

@bradfitz points out that maybe there's no good reason to disallow strings -> bytes or vice versa (obviously we can't have both). So the effect of one or the other should be considered too.

[bradfitz]

@randall77, do you want to make this decision?

I'm fine with either a new internal package, or strings depending on bytes. (if we have to pick a dependency direction, it intuitively makes more sense for strings to depends on bytes, since strings are made of bytes... but that's pretty arbitrary)

[randall77]

Here's the list of assembly functions that are currently in runtime that don't actually implement the runtime API:

bytes·Compare
bytes·countByte
bytes·Equal
bytes·IndexByte
bytes·indexShortStr
bytes·supportsVX
reflect·call
strings·countByte
strings·IndexByte
strings·indexShortStr
strings·supportsVX
sync∕atomic·AddInt32
sync∕atomic·AddInt64
sync∕atomic·AddUint32
sync∕atomic·AddUint64
sync∕atomic·AddUintptr
sync∕atomic·CompareAndSwapInt32
sync∕atomic·CompareAndSwapInt64
sync∕atomic·CompareAndSwapUint32
sync∕atomic·CompareAndSwapUint64
sync∕atomic·CompareAndSwapUintptr
sync∕atomic·LoadInt32
sync∕atomic·LoadInt64
sync∕atomic·LoadPointer
sync∕atomic·LoadUint32
sync∕atomic·LoadUint64
sync∕atomic·LoadUintptr
sync∕atomic·StoreInt32
sync∕atomic·StoreInt64
sync∕atomic·StoreUint32
sync∕atomic·StoreUint64
sync∕atomic·StoreUintptr
sync∕atomic·SwapInt32
sync∕atomic·SwapInt64
sync∕atomic·SwapUint32
sync∕atomic·SwapUint64
sync∕atomic·SwapUintptr
syscall·naclWrite
syscall·now
time·now

I think all the sync/atomic ones are for the race detector. The other non strings/bytes ones are very special cases that probably need to remain in runtime. So I think just solving this problem for strings/bytes is enough.

I'm ok for these functions to live in bytes, and have strings import bytes. I'd really rather have them live in internal/???, but I can't think of a good name for ???. bytealg? Suggestions welcome.

I'll fix this for 1.11. strings->bytes unless someone comes up with a good name.

[mvdan]

Perhaps a combination of runtime or internal with bytes? Like rbytes or runbytes.