Re: [go-nuts] Re: Slice reuse + GC

On Fri, Mar 27, 2020 at 8:19 AM Leszek Kubik wrote: > A fix for the situation of the topic could be implemented by the slice type. > Imagine, if a slice value not only shared the pointer to the underlying > buffer but also a list with references to all other slices holding on to the >

Re: [go-nuts] Re: Slice reuse + GC

Wait, by saying it would be nice to have the GC not trace elements between len and cap, you mean it would be nice to have GC recognize unreferenced elements of a slice between len and cap and free them (presumably if they are pointer or interface types)? OK, I would say Go has quirks but I'm

Re: [go-nuts] Re: Slice reuse + GC

It's common practice to *write* to elements between the length and capacity of a slice. Usually, you use append to do that. It's bad practice to *read* elements between the length and capacity. Which you can't do with a simple indexing op, of course. You would have to reslice larger and then

Re: [go-nuts] Re: Slice reuse + GC

> I disagree. I do that all the time. It's also how `append` was implemented > before it existed as a predeclared function. It's also, FWIW, used in > bytes.Buffer . I agree that > unless your API is very clear about it, you shouldn't really

Re: [go-nuts] Re: Slice reuse + GC

On Thu, Mar 26, 2020 at 6:57 PM Leszek Kubik wrote: > AFAIK it is allowed to re-slice past the len but it's rather not the way > slices should be ever used. > I disagree. I do that all the time. It's also how `append` was implemented before it existed as a predeclared function. It's also, FWIW,

[go-nuts] Re: Slice reuse + GC

AFAIK it is allowed to re-slice past the len but it's rather not the way slices should be ever used. The word slice implies taking a portion from a bigger thing and that's always safe. When you append to the slice however, there's no new allocation if the underlying buffer still has place past