You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
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
added
the
v2
A language change or incompatible library change
label
Feb 27, 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.Would expand to:
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
.The text was updated successfully, but these errors were encountered: