var x []io.ReaderCloser = ...
y := ([]io.Reader)(x)
y[0] = ... something that is a Reader, but not a Closer ...

What is now in x[0]? Can it be closed?

x[0] is still an io.ReadCloser, y[0] is an io.Reader that can be type asserted to io.ReadCloser inside the calling function (but it doesn't have to)

x[0] is still an io.ReadCloser

But it isn't, I just assigned something that doesn't have a Close method to x[0] (via y[0]).

Or are you suggesting that the cast make a copy of the slice's backing store?

I'd assume it'd have the same logic as:

var rc io.ReadCloser
var r io.Reader = rc

rc is still io.ReadCloser, r refers to that rc but it is an io.Reader.

Pretty much I'd expect this to happen under the hood, with compiler protection against invalid conversations of course.

https://play.golang.org/p/4boZqBvZIVJ

FAQs on this topic:

https://golang.org/doc/faq#convert_slice_of_interface
https://golang.org/doc/faq#convert_slice_with_same_underlying_type

I'd say the OP should have tagged this as go2, those FAQs apply to go1.

var rc io.ReadCloser
var r io.Reader = rc
rc is still io.ReadCloser, r refers to that rc but it is an io.Reader.

That works fine because the assignment at line 2 makes a copy. The value contained in rc is never modified.

The situation with slices is more like this:

var rc io.ReadCloser
rcp := &rc
rp := (*io.Reader)(rcp)
*rp = ... something that is a Reader, but not a Closer ...

Now what does rc contain?

To be problematic, you need to be able to write an io.Reader to a slot that originally contained an io.ReadCloser.

@OneOfOne Those FAQs apply to Go 2 as well. They explain why the language is as it is, and there is no reason to think that would change in Go 2. (Though I agree that this is a Go 2 proposal.)

To be problematic, you need to be able to write an io.Reader to a slot that originally contained an io.ReadCloser.

That is a very good point, hadn't thought about that. I guess it could be solved by panicking in this case instead of throwing a compiler error, but I'm not sure it's better.

Java throws ArrayStoreException. Nonetheless, I would consider covariant arrays to be one of Java's biggest mistakes: it reduces compile-time type safety, and requires extra run-time overhead to compensate. It also complicates both variable-length argument passing and generics.

What you want is copy() or append() between slices of compatible interfaces.

See also #38385

Based on the discussion above, this is a likely decline. Leaving open for four weeks for final comments.

I would like to echo @networkimprov and suggest limiting this proposal to copy() and append(). These functions do not write mis-typed values to the destination or source slice, so the following can be safe:

type Base interface {
        ...
}
type Specific interface {
        Base
        ...
}

func AppendMixed(dest []Base, src []Specific) (res []Base) {
        return append(dest, src...)
}

Currently, this does not compile and instead requires a loop.

cc @griesemer for thoughts re copy() and append() between compatible interface slices...

Right now copy and append only have one special rule: they permit a string to be copied or appended to a []byte. We'd rather not add additional special rules for them.

In general, other than string to []byte exception, it seems best to consider copy and append as generic functions that happen to be builtin to the language. We don't want to introduce additional conversion rules for them.

Still a likely decline. Leaving open for another week.

-- for @golang/proposal-review

Alternatively, the compiler can recognize the loop and convert it to the equivalent of memcpy. For any loop of copy or append of interfaces.

In general converting from one interface type to another requires changing the value to use a different method table. It can't be implemented as memcpy.

I think that the arguments against this (hasty) proposal are good. Feel free to close the issue :)

No change in consensus.