x/exp/slices: mention possible memory leak in Compact doc

[Deleplace]

What version of Go are you using (go version)?

$ go version
go version go1.19 darwin/amd64

Does this issue reproduce with the latest release?

Yes

What did you do?

I read the documentation comment of Compact

What did you expect to see?

A warning about the "right tail" values in the original slice, which are obsolete but may still contain pointers to large objects. The same problem applied to Delete (issue #54650, CL 425895 ) and was mitigated by updating the func doc.

What did you see instead?

"Compact modifies the contents of the slice s; it does not create a new slice."

Compact does not zero the "discarded" elements beyond the length of the returned slice, as can be read in the current implementation, which may have adverse memory consequences, as show by this sample code.

I will make a CL with an extra sentence in the func doc.

[Deleplace]

The same concern applies to CompactFunc, however CompactFunc's doc needs not be updated, because it already states "CompactFunc is like Compact".

[gopherbot]

Change https://go.dev/cl/426374 mentions this issue: slices: mention possible memory leak in Compact doc

[heschi]

cc @ianlancetaylor

[beoran]

@Deleplace I would think that in stead of documenting the memory leak, it should be fixed. Otherwise people will have to implement their own safer Compact.

[randall77]

@beoran I see it the same as slicing. If you have

s = [A B C D E]
s = s[:3]

Then there remain "invisible" references to D and E. The slicing operation does not zero the elements you sliced off for you.

[beoran]

@randall77 Actually, I never thought about this, I will have to be more careful with slicing like this from now. Still, as long as I have the original array, I can zero the unnecessary elements. It would be useful if there was a generic operation that did this, and Compact seems like the ideal candidate.