Skip to content
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

Jump to bottom

proposal: spec: allow append(string, ...) and view the string argument as a byte slice #43429

Closed
go101 opened this issue Dec 30, 2020 · 6 comments
Closed

proposal: spec: allow append(string, ...) and view the string argument as a byte slice #43429

go101 opened this issue Dec 30, 2020 · 6 comments
Labels
FrozenDueToAge Proposal
Projects
Proposals (old)
Milestone
Proposal

Comments

@go101
Copy link

go101 commented Dec 30, 2020 •
edited

Search append([]byte( in the Go project, there are at least 8 append calls
with the first arguments as conversions from string to []byte.
If the first argument of such an append call is allowed to be a string,
then an unnecessary allocation may be avoided.
Although it looks the official Go compiler has made an optimization here
to avoid the unnecessary allocations, (in fact, not made yet) but the proposal makes
Go code more consistent (with the second arguments, which can be strings already)
and look cleaner.

Besides these aforementioned benefits (cleaner, more consistent and efficient),
this change could also partically remedy the fact of lack of a simple way to
decap the first arguments of append calls (for the scenarios they are []byte).

We can use a string(aByteSlice) conversion as the first
argument of an append call to hint that the first argument is decaped.
It is easy for compilers to not make an allocation for such conversions.
@gopherbot gopherbot added this to the Proposal milestone Dec 30, 2020
@go101 go101 changed the title Proposal: allow the first arguments of append function calls to be strings Proposal: allow the first arguments of append function calls to be strings if they are sopposued to be byte slices Dec 30, 2020
@go101 go101 changed the title Proposal: allow the first arguments of append function calls to be strings if they are sopposued to be byte slices Proposal: allow the first arguments of append function calls to be strings if they are supposed to be byte slices Dec 30, 2020
@ianlancetaylor ianlancetaylor changed the title Proposal: allow the first arguments of append function calls to be strings if they are supposed to be byte slices proposal: allow the first arguments of append function calls to be strings if they are supposed to be byte slices Dec 30, 2020
@ianlancetaylor ianlancetaylor added this to Incoming in Proposals (old) Dec 30, 2020
@rsc
Copy link
Contributor

rsc commented Jul 14, 2021

This proposal does not make Go more consistent, as claimed.
Instead, it introduces a special case where the type returned by append is different from the type of the first argument.
This makes Go less consistent.

It would be completely fine for the compiler to optimize away the allocation in append([]byte(s), moreBytes...) of course. But the language change seems like a non-starter.

@rsc rsc changed the title proposal: allow the first arguments of append function calls to be strings if they are supposed to be byte slices proposal: spec: allow append(string, ...) returning []byte Jul 14, 2021
@go101
Copy link
Author

go101 commented Jul 15, 2021

Instead, it introduces a special case where the type returned by append is different from the type of the first argument.

I mean it makes append(aByteSlice, aString...) less lonely special.
By interpreting strings as immutable byte slices, many explanations will be more consistent.

@rsc
Copy link
Contributor

rsc commented Jul 21, 2021

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

@rsc rsc moved this from Incoming to Active in Proposals (old) Jul 21, 2021
@rsc rsc mentioned this issue Jul 21, 2021
Open
@go101 go101 mentioned this issue Jul 28, 2021
Open
@rsc
Copy link
Contributor

rsc commented Jul 28, 2021

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

@rsc rsc moved this from Active to Likely Decline in Proposals (old) Jul 28, 2021
@go101
Copy link
Author

go101 commented Jul 29, 2021

OK. But it looks there are no effective discussions here.

@go101 go101 mentioned this issue Jul 29, 2021
Open
@rsc rsc moved this from Likely Decline to Declined in Proposals (old) Aug 4, 2021
@rsc
Copy link
Contributor

rsc commented Aug 4, 2021

No change in consensus, so declined.
— rsc for the proposal review group

@rsc rsc closed this as completed Aug 4, 2021
@go101 go101 changed the title proposal: spec: allow append(string, ...) returning []byte proposal: spec: allow append(string, ) and view the string argument as a byte slice Sep 15, 2021
@go101 go101 changed the title proposal: spec: allow append(string, ) and view the string argument as a byte slice proposal: spec: allow append(string, ...) and view the string argument as a byte slice Sep 15, 2021
@golang golang locked and limited conversation to collaborators Sep 15, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge Proposal
Projects
No open projects
Proposals (old)
Declined
Milestone
Proposal
Development

No branches or pull requests
3 participants
@rsc @gopherbot @go101