Actually *T was not a good example to make my point, as we can start debating about the GC walking the references and freeing the data pointed to. However when you have []T, and you refer to some continuous buffer of memory with some chunks [0:5] (gap) [50:100], etc there's not much benefit of "freeing" the elements in-between. Anyway, I assume slices are meant to be an abstract pointers to arrays and thus they should only change the visibility not the array
On Thursday, March 26, 2020 at 7:19:16 PM UTC+1, Leszek Kubik wrote: > > I let you consider an example: > > s := make([]*T, 100) > s1, s2, s3 := s[:50], s[50:], s[:] > (.... x lines of code) > s1 = s1[:5] > > Would you like the GC to free the elements past the last s1 slice len? > What if s2, s3 are still used somewhere... > > > On Thursday, March 26, 2020 at 7:01:34 PM UTC+1, robfig wrote: >> >> I see, thank you. >> >> RE reducing the capacity, I want to distinguish freeing the memory (1) >> used for the slice and (2) referred to by the slice elements. I can easily >> see that freeing (1) is hard and not so beneficial, but I can't see why (2) >> would be difficult, and the benefit seems potentially much larger. In our >> case, each slice element has a handle to a sizable []byte, so that's why I >> was interested to know if they would remain live. >> >> As an aside, (1) was addressed by Ian here: >> https://groups.google.com/d/msg/golang-nuts/sVhjhiYLXNg/YNZ_H-JsBAAJ >> >> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/57d4b27d-c650-492c-b931-aab0fbf39c68%40googlegroups.com.
