Go's sort.reverse function returns a pointer?

See more:

Go

i'm currently learning go and i'm at interfaces point in the course now. the sort package seems to be a good thing to learn about, not just because you can sort stuff, but also because the "Interface" interface is needed to do some of the work.

(tl;dr: read the next paragraph, check the snippet of source and then scroll to the bottom and continue reading from the bold line)

now i had no idea what was going on when you do a reverse sort. i thought "sort.Reverse" reversed the elements, then you pass it to "sort.Sort" and that seemed redundant. so off to the source i went, and i found this gem in sort.go[^] (line 291 - 293):

func Reverse(data Interface) Interface {
	return &reverse{data}
}

i played around a bit here[^] to see what would happen if i returned a pointer to my struct or just the struct without the pointer.

i went around the internet today at work, but couldn't find anybody who addressed that bit of code. i did however find a lot of talk about "escape analysis", which is how go's compiler figures out whether a value should go on the stack if it can be discarded when the function returns, or whether the value will still need to be accessed after the function ends which then causes it to be placed on the heap. this optimisation is done for you.

that then got me thinking:

is this a "legacy" piece of code (the snippet above)? is that the way they did it to ensure that the struct is not discarded after the function returns? in the go playground bit i added in, i returned a struct and then changed it to a pointer to the struct, but no matter which one i returned, the underlying string slice still had its first value changed. slices are reference types, so if there is a reference to that slice in the function that calls "sort.Reverse", is it really necessary to return a pointer to the struct it's wrapped in?

i do understand the reason they wrap the slice in the struct, but the pointer bit is what my mind has been stuck on since last night (i think i was even dreaming about it).

have i got the right idea here, or am i overthinking it?


oh! this just popped into my head before i posted:

the struct sort.reverse is not exported (not capital letter), however, you need to still use this struct for your reverse sorting. is the answer to my headache as simple as "because the item is not exported, and you still need to have access to it, the struct is placed on the heap and you get a pointer to it, which you can then access freely"?

i think i'll go and expand on my golang playground code snippet and shove things in modules to test this theory... unless someone beats me to an explanation.

Update:

ok, no. it's not because of the exporting. i'm back at my first idea of escape analysis.

What I have tried:

looking at the golang source, googling and i'll now try to figure it out on my own again.