To emphasize the wisdom:
With an implicit conversion like you mentioned, the F(x) invocation at
the bottom expects B.SomeFunc() will be called but in fact,
A.SomeFunc() will be called. That's why this is an error. You can
still do F(A(x)), which explicitly makes a copy of x as an A.
This is not just a "Go style" issue, this is the result of distilling
lessons of millions of C++ developer's billions of hours of debugging and
large program / large team / long timeline development experience. Things
that are missing from Go, or restricted in Go, or even "adversarial" in Go
are there mostly because of hard-won experience. Many subtle design virtues
are what's missing as much as what's present.
On Sat, Jun 8, 2019 at 8:53 PM Burak Serdar <bser...@ieee.org> wrote:
> On Sat, Jun 8, 2019 at 3:22 PM Michael Ellis <michael.f.el...@gmail.com>
> wrote:
> >
> >
> > On Friday, June 7, 2019 at 3:01:04 PM UTC-4, Burak Serdar wrote:
> >>
> >>
> >> If one library defines string.Render() for html, and another defines
> >> another string.Render() for, say, a graphics library, which Render
> >> will be called when I call "str".Render()?
> >>
> > Thanks for the explanation. That makes sense. Thinking it over, I'm
> wondering what would be required for the compiler to recognize synonyms of
> the form 'type Foo Bar' and allow passing a Foo for an argument of type
> Bar. The compiler knows the expected type of each function argument so it
> seems as if checking to see if a passed argument is a simple synonym for
> the expected type and doing a coercion doesn't seem like a big task. Note
> that this is different than asking for, say, numeric conversion from int to
> float64 because those types are not synonyms. I actually like the fact
> that Go forces you to explicitly convert numeric types.
>
> If you have:
>
> type A int
> type B A
>
> then A and B are not synonyms, they are different types. Because of
> Go's type system:
>
> func (a A) SomeFunc() {}
> func (b B) SomeFunc() {}
>
>
> func F(value A) {
> value.SomeFunc()
> }
>
> x:=B{}
> F(x)
>
> With an implicit conversion like you mentioned, the F(x) invocation at
> the bottom expects B.SomeFunc() will be called but in fact,
> A.SomeFunc() will be called. That's why this is an error. You can
> still do F(A(x)), which explicitly makes a copy of x as an A.
>
> This is one of the reasons why it is so easy to read and write Go
> code. Most of the time you can comprehend the code with only local
> knowledge.
>
>
> >
> >
> > --
> > 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.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/aa26152a-fc5c-4048-9d30-446960df0ea9%40googlegroups.com
> .
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAMV2RqrLJOqhqsrBv4gK7FunSA4SLPNDr2y0xSB5dvyMs4q-Pg%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>
--
*Michael T. jonesmichael.jo...@gmail.com <michael.jo...@gmail.com>*
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CALoEmQyO-SK38pLaH4u4qAWbKs5uU%3DaXE%3DH34Ab-tR-WvU2A7Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
