static conversion of interface types fails

[rogpeppe]

some quotations from the manual:

``Two interface types are identical if they have the same set of methods with the same
names and 
identical function types. The order of the methods is irrelevant.''

``Type compatibility is less stringent than type identity: a named and an unnamed type
are compatible if 
the respective type literals are compatible. In all other respects, the definition of
type compatibility is the 
same as for type identity listed above but with ``compatible'' substituted for
``identical''.''

``In general, a conversion succeeds if the value of x is assignment compatible with type
T, or if the value 
would be assignment compatible with type T if the value's type, or T, or any of their
component types 
were unnamed.''

i'm not quite sure what a "type literal" means for an interface type,
but perhaps it's not unreasonable to assume that it's the value
from which the interface is made.

this makes me believe that the following program should work
(and in fact it would be useful if it did, as it enables the inter-operation
of interface types from different packages, even if some of their
component types happen to be named differently).

1. What is a short input program that triggers the error?

package main
type Y int
type X1 interface {
    foo() int
}
type X2 interface {
    foo() Y
}
type T1 bool
func (t T1) foo() int {
    return 99
}

type T2 bool
func (t T2) foo() Y {
    return 99
}

func main() {
    t1 := T1(false)
    t2 := T2(t1)       // demonstrate conversion of type literals

    x1 := X1(t1)
    x2 := X2(t2)

    fail := X2(x1)

    t1.foo()
    t2.foo()
    x1.foo()
    x2.foo()
    fail.foo()
}


2. What is the full compiler output?

tst.go:26: need type assertion to use X1 as X2
    missing foo() Y



3. What version of the compiler are you using?  (Run it with the -V flag.)

8g version 5516+

[griesemer]

Comment 1:

A "type literal" is the source text describing the respective type. For an interface
type, the type literal is the text from "interface{" to the closing "}" (see: 
http://golang.org/doc/go_spec.html#Types ).
Conversions are primarily intended to operate on concrete (i.e., non-interface) types; a
conversion is concerned about the value (and possibly changing it) and 
ignores any associated methods. Interface types (i.e., abstract types) don't say
anything about values, only methods. One might argue that conversions shouldn't be 
allowed on interfaces in the first place, and converting a value of a concrete type to
an interface (say X1(t1)) is only useful to obtain the interface type, say for a 
variable declaration (as in: x1 := X1(t1)). Conversely, the opposite operation
(converting an interface variable to a concrete type) is strictly forbidden; instead a
type 
assertion is used (because it may fail, while conversions never fail).
That said, converting an interface type to another interface type is strictly a typing
operation; only methods are involved. Furthermore, function conversions, such as 
in:
type F1 func(x Y) int
type F2 func(x int) Y
var f1 F1
var f2 F2
f1 = F1(f2)
f2 = F2(f1)
(using type Y int) are perfectly legal.
Thus a conversion of the form X2(x1) (as in your example) is essentially a set of method
(function) conversions. Arguably that should be allowed.

Owner changed to g...@golang.org.

Status changed to Thinking.

[griesemer]

Comment 2:

In fact, gccgo accepts your code just fine. I am considering this a 6g bug at this
point. Also, the spec should 
probably be a bit clearer about cases like this.

Status changed to Accepted.

[rogpeppe]

Comment 3:

that was my thinking too.
it might help to explain the scenario that caused me to think about this.
in package nacl/av, Image implements an interface that is compatible with
exp/draw's Context. but nacl/av does not have exp/draw as a dependency.
if a method were to be added in draw.Context that took, for example,
draw.Rectangle as an argument, it would then no longer be possible
for av to implement draw.Context without introducing exp/draw as a dependency.
a static interface type conversion such as the one above would
allow this.

[rogpeppe]

Comment 4:

oops, i sent that last remark before i saw the previous one.

[griesemer]

Comment 5:

More evidence in support of the above interpretation of the spec. The following program:
package main
type S struct{ x int }
type X3 interface {
    foo() struct{ x int }
}
type T3 bool
func (t T3) foo() S {
    return S{0}
}
func main() {
    t3 := T3(false)
    var _ X3 = t3  // t3 is assignment compatible with X3
    var _ = X3(t3)  // conversion legal because t3 is assignment compatible with X3
}
is accepted by 6g; it accepts the t3 interface as compatible with X3 despite the fact
that the result type of foo() is merely "compatible" and not 
identical. The respective conversion is legal as a consequence.
Using the argument:
``In general, a conversion succeeds if the value of x is assignment compatible with type
T, or if the value 
would be assignment compatible with type T if the value's type, or T, or any of their
component types 
were unnamed.''
t3 should be convertible to an X2 even if the result type of T3's foo() were a named
type T with T struct{x int}.

Owner changed to r...@golang.org.

[griesemer]

Comment 6:

There's more to this than meets the eye at first glance. If this kind of interface
conversion is permitted, one might argue that the assignment:
type X interface {
    foo() struct{ x int }
}
type S struct{ x int }
type T bool
func (t T) foo() S {
    return S{42}
}
...
var t T
var x X = t
should be legal on the grounds of "asignment compatibility". However, a fundamental
assumption about how interfaces work is that the method's 
signatures have to be identical.
Furthermore, depending on the implementation, a conversion of the form X2(x1) as
suggested in the original issue report may require runtime work (to 
possibly re-map method tables).

Owner changed to g...@golang.org.

Status changed to Thinking.

[griesemer]

Comment 7:

The most recent language changes clarify assignments and conversions and this conversion
remains illegal:
test.go:26: cannot convert x1 (type X1) to type X2: X1 does not implement X2 (wrong type
for foo method)
    have foo() int
    want foo() Y

Status changed to WorkingAsIntended.