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.
