Why did you expect to see "42 554"?

What do you think should change in the blog post?

In general we don't use the issue trackers for questions about how Go works. Please see https://golang.org/wiki/Questions. Thanks.

I'm going to lose this because I see nothing wrong here. Please comment if you disagree.

@ianlancetaylor I think he's right. Previously I was also of the impression that it's wrong but I think @kwangh is correct.

Look at: #30169

So, with this CL, Find, FindAll, FindAllSubmatch have the capacity the same as their length.

But the blog reads:

This code behaves as advertised, but the returned []byte points into an array containing the entire file. 
Since the slice references the original array, as long as the slice is kept around the garbage collector 
can't release the array; the few useful bytes of the file keep the entire contents in memory.

So, with that CL, return []byte points into a subset of that array and not the entire file anymore and can't be resliced back to the original capacity (if needed) in this particular case.

So, if I understand this correctly, maybe the blog could be updated with a different example to show that "Gotcha" but not using the Find and friends from regexp. And it'd really nice if I could contribute if there's a need!

Would a simpler example be sub slicing the last 10 bytes off a multi megabyte string; that would remove the debate between the subslices Len and cap as neither can be used to reference the megabytes of prefix

@shmsr Thank you for the extra explanation.
I think the blog post need a new example.

@shmsr The blog post is still correct with the current garbage collector. The fact that the capacity is now restricted doesn't matter. The entire underlyng array is still pinned.

@ianlancetaylor It's a bit late but sorry for using issues. So in short, the underlying array is in heap place, and even after the CopyDigits function returns a result, the underlying array still stays in the heap space. The capacity does not matter. Thank you.

Yes, I get that. I didn't say that there's a problem with the underlying array getting GC'ed. I think I wasn't really clear before in explaining my thought. I just felt that the following line could be changed a little (or the example):

This code behaves as advertised, but the returned []byte points into an array containing the entire file

Because it points to an array which is not containing the entire file anymore (but a subset of that file); hence can't be resliced back even if the users want to. A slight change to the blog might make things very clear (maybe).

I hope I'm clear now. I explained the same thing before (#43235 (comment)) as well.

So, do you think that the following line needs some correction?

This code behaves as advertised, but the returned []byte points into an array containing the entire file

But that again is also not true every time. The blog post is totally fine is the file contains only numbers as regexp.Find will return the leftmost match and basically it'll point to an array containing the entire file. Now suppose the file contains:

123abc456

Then it's is a bit confusing if one looks at the implementation of regexp.Find and the blog. Maybe my interpretation of the blog is wrong; feel free to correct me.

I think the word "into" make the sentence correct.

Do you have a suggestion for how to make it more clear? Thanks.