This comment has been minimized.

This will require allocating a slice under the covers. []int and []interface{} do not have the same memory and unless something magic happens, the only way to achieve this is to allocate the []interface slice and run the loop. In other words, except for microoptimizations this must do what the current user-written code does, and involves an allocation and an O(len(slice)) copy.

I am not making an argument for or against, just saying something that should appear in the proposal.

This comment has been minimized.

Perhaps confusingly, I've actually made two proposals here. In the first one, only the copy and append primitives are affected, and no slice will need to be allocated under the covers. In the second ("Alternative proposal") one, yes, a new slice would need to be allocated, which I hope I've made a little clearer now.

This comment has been minimized.

cznic: At this point I think I'm mostly trending towards the second proposal, because it's actually reasonably intuitive that the "..." modifier could (when necessary) assign each element in turn,
and use of that modifier is a good potential signifier of a "allocation may occur here" place.

As for readability, I don't think it would make for less readable code, but perhaps you're seeing
something I'm not. Can you give an example of where it would make code less readable?

This comment has been minimized.

I believe the name copy() communicates the intention of what is happening very well, it does not make it look like magic. Plus it already does some magic, at least for string/[]byte copies. But also the type conversions string([]byte]) and []byte(string) do hidden copies.

This comment has been minimized.

I really want to like the alternative proposal, but I think it is important that you must explicitly indicate that your are making an allocation. Like fmt.Println(range xs…) but that syntax feels out of place...any ideas?

Another possibility (is it the right place?) that would fulfill the use case in the document would be to only have make assignment-compatible. That is, allow the seconde parameter (replacing the size) to be a slice* of a type assignable to the slice type of the first parameter.
Keeping the use case in the document, that would give:

This comment has been minimized.

edited

update: I just saw the part about the alternative proposal -- indeed that would involve a slice allocation in the worst case.

@robpike (not taking a stance on this proposal), but I don't believe that a slice "allocation" would be necessary as you described. There are two cases:

append(dst, src...)

append(dst, elem1, elem2, elem3)

In the first case, the source is already a slice (thus no allocation is needed). append and copy would simply need to be generalized to accept a src whose elements are assignment-compatible to dst, and perform an assignment loop; the current memcpy case would just be an optimization.

In the second case, the compiler can place an array on the stack (in the above example, a [3]T). It could derive a slice header from this stack-resident array, and place that on the stack as well -- in any case, this is a throwaway slice that clearly does not escape, and thus should never end up on the heap. If it's considered an allocation, it's certainly not an expensive one.

This comment has been minimized.

Normally I interpret "Go 2" to mean language changes that are impossible without breaking backwards compatibility. Has the definition been changed to "non-urgent language changes"? Or did I misunderstand "Go 2"?

This comment has been minimized.

@carlmjohnson What comprises "Go 2" or it's timeframe have not been defined yet. That said, while many agree that this might be a nice expansion on append and copy, there's no urgency. In the interest of keeping unnecessary language churn at a minimum, the decision was to postpone so we can look at this within the larger context of Go 2.

(There has been at least one other proposal in related direction, and we should probably consider all our options before venturing out to a relatively involved change to append.)

This comment has been minimized.

edited

It seems from the examples given that the need that triggered this proposal is array types conversion. But the syntax proposed is awkward. Go already has a type conversion syntax and it already has magic (that does allocation, copy and conversion) to convert []byte to string and the reverse.
So instead of adding magic to append and copy, a simpler syntax change would just be to just extend the type conversion syntax to have magic for any array type.
Here are the examples of the proposal adapted for this syntax:

However I'm not endorsing this proposal. Instead, I am against it as it hides a costly conversion (that requires allocation, loop, conversion of each array element) under a very short syntax that people will abuse. Currently code for array conversions is verbose because this is costly at runtime, and I'm fine with that.

Also, regarding append doing "extra allocations" and "O(n) complexity", I don't really undrestand the concern: AFAIK, both copy & append are already expected to do an extra allocation (of the new array; possibly amortized in case of append), and have O(n) complexity (both of them are by definition a shorthand for a loop).

Also, for me personally, the above proposed pattern seems short enough, and at the same time implicit enough (the loop and the allocation are all clearly visible by virtue of using append, and the target type is also clearly listed), that I don't see a need for the "alternative proposal".

edit: Also, I see it as further advantage of the proposal that it could become the single recommended solution the 3+ "commonly used" variants of the "covariance conversion code pattern", i.e.:

removing the need for choice here and attempts at microoptimization by using len(xs) here and there. And as such, could possibly become a recommended response to #7512, maybe even landing in the FAQ.

edit 2: Regarding "implicitness" of the conversion, note that in the above loops (variant b and c), the append already does an implicit conversion of the x from int to interface{}. In my book, keeping the []interface{} phrase closer to the append could make it actually more explicit.