-
Notifications
You must be signed in to change notification settings - Fork 17.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
test: add test that we don't optimize string([]byte(string)) #25834
Comments
Echoing @rsc (over in #25805): Given that almost no one will know what Maybe adding package |
Except that |
I agree we can add a test to not accidentally break existing code. But I also would say that a strings.DeepCopy function or alike (that only allocates once instead of twice) would be nice to replace existing uses of string([]byte(s)) (which afaik the language spec does not mandate needs to allocate) and can be a new faster alternative. New proposal issue? |
Well, to be precise, that should be allowed if (and only if) |
Change https://golang.org/cl/118295 mentions this issue: |
Fixes golang#25834 Change-Id: I33e58dabfd04b84dfee1a9a3796796b5d19862e7 Reviewed-on: https://go-review.googlesource.com/118295 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
From discussion with @golang/proposal-review related to #25805 but mostly unrelated,
We should verify that we have or add a test that
string([]byte(s))
doesn't reduce to justs
ever. We should test that we always make a copy and return a new string with a new (internal) data pointer.@rsc mentioned as a use case making a copy of a small part of a large string to prevent the GC from retaining the large string.
/cc @martisch @josharian
The text was updated successfully, but these errors were encountered: