[arnehormann]

It doesn't need to. You could also write type Runes []rune but the struct variant has the advantage that you can get the array back without any conversions - it's pretty cheap. And you can embed it. That's an advantage if you e.g. don't define Less on Runes but define it on RunesAsc and RunesDesc. See http://golang.org/pkg/sort/ -> Examples (SortWrapper)

[arnehormann]

The costs: allocating the memory, having it set to zero values and keeping the garbage collector a little busier. All of that more than once if you don't keep the conversions down. Profile and disassemble your program, Go comes with pretty great tools!

[dvisher]

The Go runtime sets all memory to zero at the start of the program's execution, meaning there is no overhead for 'setting the zero values'. The amount of extra memory allocated is minimal (probably zero). Records/structs tend to be figured out at compile time so no 'extra' information needs to be stored in it. And since we are storing a pointer (a slice) the struct is already aligned so no extra storage is needed there. What it might cost is one extra level of indirection per array access, but due to the simplicity of the program, I would not be surprised if this was removed at compile time or cached (in hardware). Looking at the disassembly itself, they seem to optimize out that extra layer of indirection as well (for the most part in Swap, Len, and Less).

The real cost of this is definitely the verbosity for something that could be much simpler.

[azth]

What cost do conversions incur?