Ah, ok. I think I understand what you're saying. In my opinion, there's a
difference between automatically type casting between a concrete type and
an interface (or from one concrete type to another) and automatically
casting between two compatible (or identical) interfaces.
Not automatically converting anything involving a concrete type makes sense
to me. But not automatically recognizing that two interfaces that implement
the same methods are the same in some situations but not in others strikes
me as a surprising limitation on implicit interfaces.
Thanks,
Jon
On Monday, July 4, 2016 at 11:24:18 AM UTC-4, Constantin Konstantinidis
wrote:
>
> I understand your concern. What I like a lot in Go is the strong type side
> that requires strict structure including naming.
> I'm only pointing that if the compiler cannot "type" a result, it should
> always mention it.
>
> Regards,
>
> On Monday, July 4, 2016 at 5:16:57 PM UTC+2, Jon Bodner wrote:
>>
>> Hi Constantin,
>>
>> Thanks for responding.
>>
>> This is a case where I think the compiler should be perfectly capable of
>> figuring out that ResultA and ResultB are identical, and allowing one to be
>> substituted for the other. As the adapter shows, the compiler can figure
>> this out when it's a return type, but can't figure it out when you want to
>> match if a type implements a particular interface. That feels inconsistent
>> to me, especially since it can be solved with a trivial adapter that
>> doesn't even have to cast to work.
>>
>> Ian pointed out that there was an issue recently created that addressed
>> this. I'm hoping that it can make it into Go 1.8 and I'm interested in
>> finding out what I can do to help that happen.
>>
>> Jon
>>
>> On Monday, July 4, 2016 at 10:54:03 AM UTC-4, Constantin Konstantinidis
>> wrote:
>>>
>>> It seems to me that the compiling error is adequate guidance.
>>> fmt.Printf("%v %T",V.Calculate(2,8)) displays 10 %!T(MISSING)
>>> ie Calculate returns a untyped value.
>>> If you try to set the type by using the standard interface of type
>>> CalcB fmt.Println(ib.Calculate(CalcB(i)).Result()) then the compiling error
>>> is
>>>
>>> prog.go:40: cannot convert i (type int) to type CalcB:
>>> int does not implement CalcB (missing Calculate method)
>>> prog.go:40: cannot use CalcB(i) (type CalcB) as type int in argument to
>>> ib.Calculate
>>>
>>>
>>> which confirms that Calculate method typed as ResultA fails probably
>>> because the compiler considers unclear what should be achieved.
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Monday, July 4, 2016 at 5:29:32 AM UTC+2, Ian Lance Taylor wrote:
>>>>
>>>> On Sun, Jul 3, 2016 at 12:27 PM, Jon Bodner <j...@bodnerfamily.com>
>>>> wrote:
>>>> >
>>>> > I'm working on a DAO adapter layer helper called Proteus
>>>> > (https://github.com/jonbodner/proteus), and ran into an interesting
>>>> quirk in
>>>> > what Go considers equivalent interfaces. I recreated a simplified
>>>> version of
>>>> > the issue is at https://play.golang.org/p/BS3-bUKtO9 .
>>>> >
>>>> > The code that I linked does not compile, with the error:
>>>> >
>>>> > V does not implement CalcB (wrong type for Calculate method)
>>>> > have Calculate(int) ResultA
>>>> > want Calculate(int) ResultB
>>>> >
>>>> >
>>>> > ResultA and ResultB are identical interfaces; both define a single
>>>> method
>>>> > Result that takes in no parameters and return an int.
>>>> >
>>>> > However, if I put in a wrapper around V, I can get it to work:
>>>> > https://play.golang.org/p/XUoZwsBaFn
>>>> >
>>>> > What I don't understand is that the wrapper doesn't do any casting of
>>>> > ResultA to ResultB, and that's OK in this situation. But the Go
>>>> compiler
>>>> > can't figure out that ResultA and ResultB are identical without that
>>>> > wrapper. Why is that? Why does the compiler fail the first case and
>>>> pass the
>>>> > second one?
>>>>
>>>> ResultA and ResultB are assignable but not identical.
>>>>
>>>> https://golang.org/ref/spec#Type_identity
>>>> https://golang.org/ref/spec#Assignability
>>>>
>>>> For the specific case of interface types, you may be interested in
>>>> https://golang.org/issue/16209 .
>>>>
>>>> Ian
>>>>
>>>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
