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

proposal: spec: "x..." in slice literal (syntactic sugar) #19218

Closed
dolmen opened this issue Feb 21, 2017 · 4 comments
Closed

proposal: spec: "x..." in slice literal (syntactic sugar) #19218

dolmen opened this issue Feb 21, 2017 · 4 comments
Labels
FrozenDueToAge LanguageChange Suggested changes to the Go language Proposal v2 An incompatible library change
Milestone

Comments

@dolmen
Copy link
Contributor

dolmen commented Feb 21, 2017

We already have a syntax to expand a slice to give as an argument to a variadic function: slice.... Using the same syntax in slice literals would be a consistent syntactic sugar.

v := []string{"c", "d"}
w := []string{"a", "b", v...}

Would expand to:

v := []string{"c", "d"}
w := make([]string, 2+len(v))
w[0] = "a"
w[1] = "b"
copy(w[2:], v)

This slice expansion should work at any place (not just the tail like for slice expansion in calls to variadic functions in Go 1.0) in the literal. Related: #18605.

Use case: building a new slice by prepending elements to a given slice is quite common when wrapping variadic functions such as fmt.Sprintf.

@yaxinlx
Copy link

yaxinlx commented Feb 21, 2017

v := []string{"c", "d"}
w := append([]string{"a", "b"}, v...)

@mvdan
Copy link
Member

mvdan commented Feb 21, 2017

Why isn't #18605 enough? This would complicate the language and would be a much bigger change to it.

@griesemer griesemer added NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. Proposal labels Feb 21, 2017
@griesemer
Copy link
Contributor

This is what append is for (see @yaxinlx comment). Or put in another way: If we had v... for composite literals, we wouldn't need append: You could always (*) write

[]T{list..., x}      // same as append(list, x)
[]T{list..., x...}   // same as append(list, x...)

(*) assuming we know the type T.

The above requires ... to work at any place in a composite literal, not just the end. Having it only at the end smells even more like append.

In other words, we already have the functionality you wish for, perhaps a bit less elegantly, but more explicitly, with append.

I am against this proposal.

@rsc rsc added the v2 An incompatible library change label Feb 27, 2017
@bradfitz bradfitz added the LanguageChange Suggested changes to the Go language label Feb 27, 2017
@gopherbot gopherbot added this to the Proposal milestone Mar 20, 2017
@rsc rsc removed the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label Jun 12, 2017
@dolmen
Copy link
Contributor Author

dolmen commented Nov 16, 2017

I don't want this feature anymore. @yaxinlx and @griesemer convinced me.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge LanguageChange Suggested changes to the Go language Proposal v2 An incompatible library change
Projects
None yet
Development

No branches or pull requests

7 participants