Hacker News Reader

Yeah, I kept waiting for the article to mention covariance and contravariance, and it never did. A very weird explanation of a not-that-weird phenomenon; I suspect the author didn't really understand what's going on.

To be fair to the author of the article, the official Go blog, written by Go's designers, offers the same explanation as the article, unfortunately.

There was a proposal https://github.com/golang/go/issues/7512 to make interface method return types covariant, but it didn't go anywhere, and people seemed to favor the broken behavior (returning a concrete type can fail to satisfy an interface, because the crude matching doesn't care that the type has all the expected methods).

Might you or someone else have some links you could share that talk about covariance and contravariance?

Eli Bendersky has a good post[1] on the topic.

[1] https://eli.thegreenplace.net/2018/covariance-and-contravari...

Oh this is great read, thanks!

The wikipedia has a good explanation:

https://en.wikipedia.org/wiki/Covariance_and_contravariance_...

My favorite comment on this topic is from Tim Sweeney: http://lambda-the-ultimate.org/node/735#comment-6678

Going after two folks in Java and C# communities (the later being involved in developing the language) for committing the same error.

Note that in the meantime, C# has gotten this pretty right, with IEnumerable (a read-only list) and support for co- and contra-variance at type declaration time.

Hopefully, some day, Go will also get this 'obscure' feature, though I'm not holding my breath. I would be extremely surprised if their initial version of generics will support anything like this.

I'm not sure the implementation details can be ignored so easily. With certain exception, the Go authors do not like implicit conversions and the associated runtime costs.

I look at the discussion of covariance/contravariance and memory layout as two sides of the same coin.

The problem is that there is no way to pass an immutable slice to a function.

What Go really needs is a way to create abstractions that will work with the range loop syntax.

I wonder if this could be caught differently. Such as say, allowing implicitly []struct to be passed where a []interface{} is required, but only if said receiver makes no modification. Otherwise, it's a compile time error. Of course, a read only slice marker would work as well.

The "solution" is to accept an `interface{}` and pass in a `[]struct`!

"When writing generic Go, only accept `interface{}` and never a slice" is a painful maxim but works.

Well, that would allow you to call the function, but now you can't write the body of the function without reflection: you can't iterate over an interface{}, and you can't cast a []struct (edit) wrapped in an interface{} (/edit) to a []SomeInterface, so you're back to square one.

Yes, but now you no longer need to change the function declaration and all callsites (major version change) to support new types (if they're slices or not), just need to implement more reflection or typecasting cases within the function (minor version change).

Counterpoint: if you modify the call site to pass in a new value, you don't know whether the function will accept it or not, since you've opted out of any compiler verification.

That's a very weak argument since you're already opting out of every other kind of compiler check by using `interface{}` as an element type to begin with.

Yet another reason to just use `interface{}`: if the caller already has a value of type `[]Concrete` then they can just pass it in directly; otherwise the caller will need to allocate and copy the value's elements into a new value of `[]interface{}` type since the `[]Concrete` is not castable: https://play.golang.org/p/whh1mAAlN-N

My point was that it is a bad idea to write functions that take an interface{} and try to reflect on it, since you are putting out of all compiler checks. You also get a much, much slower function.

The other much less painful maxim is to take a pass on Go, and use a language that's not stuck in the early 70s and with a rabid fanbase to boot.

This one of my top Go complaints as well (and I love the language).

If Foo implements interface Bar (Baz() error, Moo() string), then I should be able to pass in []Foo to an argument expecting []Bar, because the former is a slice of a type Bar. The compiler should be a good compiler and do the needful to manage args.

All I can expect do on the called side is iterate through the slice, and call the interface function on each element. That sounds contractual to me :-).

As I explained, that is wrong. You would need a different type, let's call it read-only-slice,to support that.

To make the problem more explicit, let's say you have

    func baz(bars []Bar) {
        bars[0] = nil
    }

    type Foo struct {}

    baz(make([]Foo, 5))

In this case, the program would fail at runtime, as you can't store a nil in a slice of Foos. The baz() function is perfectly correct in itself, if you passed an array of Bars it would work perfectly.

I get that part. I want the language/compiler to allow me to use it where it makes sense (as an argument) and prohibit doing things to it that don't (as you demonstrated).

That would be nice in principle, but where do you expect the error to be thrown in the example above?

I don't know of any language which tries to automatically deduce whether a variable is used in a read-only manner or not, and base covariance on this deduction.

Even C++, which allows you to explicitly annotate an array to declare that it is read-only (const vector<base*> ) doesn't allow you to pass an array of derived elements instead, so I assume there is some difficulty in implementing these checks and ensuring correctness.