The same interface by different names

[Zellyn]

I'm posting here rather than filing a proposal on github, because I don't know the history of this idea.

Would it make sense to have the compiler loosen its type checking when using the same interface but with different names?

There are two places this would help:

- moving (or duplicating) an interface, as with the context package. Example discussion: https://github.com/grpc/grpc-go/issues/711

- using a vendored version of an interface. Example discussions abound.

The big problem occurs when comparing types that contain the interface type. For example, function parameter types:

package main

import (

"fmt"

"time"

)

type Stringer interface {

String() string

}

func func1(s Stringer) {}

func func2(s fmt.Stringer) {}

func func3(f func(s Stringer)) {}

func func4(f func(s fmt.Stringer)) {}

func main() {

e := time.Second // valid Stringer

func1(e) // ok

func2(e) // ok

func3(func1) // ok

func4(func1) // cannot use func1 (type func(Stringer)) as type func(fmt.Stringer) in argument to func4

}

Zellyn

[Zellyn]

And of course immediately after posting, I realized a better title would be: Proposal: relaxed rules for nested interface compatibility

[Robert Griesemer]

This is an interesting idea.

In this specific case though you can use a wrapper: https://play.golang.org/p/l8AfJK6I4e - and with some luck the compiler may inline away the closure and there's no cost overhead. The wrapper moves the problem to the problem of assigning interfaces, where it "works".

I agree that this restriction in the type system does impede the power of interfaces a bit. Maybe worthwhile exploring the ramifications of relaxing the rules.

- gri

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[cfo...@gmail.com]

If and only if two interfaces specify the exact same functions, then they can be type-asserted both ways.

If and only if two interfaces can be type-asserted both ways, then any function signature using either will accept exactly the same parameters as the others. (As one will be type-asserted to another automagically, and the type-assertion is guaranteed to work both ways.)

Since the method call will allow either interface to be passed into it, regardless of which interface the function will accept, and which interface it's passed…

Basically, by Type Theory, the two interfaces are technically identical, and interchangable. They're just different names to the exact same interface.

I mean, consider fmt.stringer and strings.stringer, we know they both implement the same exact functions, and are the same "type" because all assignments between them will work… forwards and backwards.

[Alan Donovan]

On 17 June 2016 at 16:40, <cfo...@gmail.com> wrote:

If and only if two interfaces specify the exact same functions, then they can be type-asserted both ways.

That's not quite true: https://play.golang.org/p/UTNVGtZRJE. Type assertions are more permissive than assignments: the compiler rejects an assertion only when there no concrete type that satisfies I1 could also satisfy I2, which in practice means that they have methods of the same name but different types.

Basically, by Type Theory, the two interfaces are technically identical, and interchangable. They're just different names to the exact same interface.

That is correct, but only because type theory is logic, and the logical consequence of a falsehood is whatever you want it to be.  ;)

[Cassie]

https://play.golang.org/p/Looxn0lE4u

TFTFY

> panic: interface conversion: interface is nil, not main.J

Sorry if I was unclear, but I'm not talking about type assertions compiling as "can be asserted both ways", I'm talking about type assertions WORKING in code as "can be asserted both ways (without panicing)".

[Alan Donovan]

On 17 June 2016 at 19:06, Cassie <cfo...@gmail.com> wrote:

I'm talking about type assertions WORKING in code as "can be asserted both ways (without panicing)".

In this example, type T satisfies two disjoint interfaces I and J, so you can write a type assertion from I to J and back again, and it will succeed dynamically if the concrete value has type T:

https://play.golang.org/p/atg84sLeMP

[Cassie]

> In this example, type T satisfies two disjoint interfaces I and J, so you can write a type assertion from I to J and back again, and it will succeed dynamically if the concrete value has type T:

Ok, I'm talking about type assertions working in code for ALL POSSIBLE IMPLEMENTATIONS, that satisfy the type, without panicing.

[Alan Donovan]

Returning to the original topic: the motivation for Zellyn's proposal is to support large-scale refactoring and vendoring.  Another solution worth considering is an alias declaration 'type I2 = I1' that would let you declare a type or variable as being identical to some other type or variable.  (Aliases for constants and functions aren't necessary because existing mechanisms like const c2 = c1 and func f2() { f1() } allow you to declare aliases that are indistinguishable from the original.)  Aliases would solve the refactoring/moving problem and would ameliorate the vendoring problem but not solve it entirely.  And it's a bigger change to the language than relaxing the typing rules for conversion and assignment, of course.

[Zellyn]

Robert,

Is there anything I should do to make this proposal more official, or are y'all considering it deep inside the mysterious Googleplex? :-)

[Ian Lance Taylor]

On Tue, Jun 28, 2016 at 1:12 PM, Zellyn <zel...@gmail.com> wrote:
>
> Is there anything I should do to make this proposal more official, or are
> y'all considering it deep inside the mysterious Googleplex? :-)

This would be a reasonable point to turn to the proposal process.

Ian

[Zellyn]

https://github.com/golang/go/issues/16209