I'm not disputing the wisdom of Go's design. As I said at the top of the
initial post, I like Go the way it is and see no need for a Go 2.
I was trying to find a clean solution to a specific use case: nestable
functions that generate html. Since new methods on primitives are not
allowed (for good reason as I now understand) I wanted to at least inquire
about the possibility of loosening the restrictions on a very specific
case: function args whose type is effectively a string (or other
primitive). I get the point the about types being not the same in terms of
Go's internal bookkeeping. However, in this particular narrow case I don't
see a hazard to maintainability because the rule forbidding new methods on
primitives excludes any possibility of confusion within the body of the
function.
To my mind, having to define a type equivalent to a primitive solely for
the purpose of implementing an interface detracts from readability. But
given that there's good reason for the requirement I think being able to
pass the equivalent primitive as a function argument of that type seems
like a potentially safe way to make the code more readable.
Just my $0.02
On Sunday, June 9, 2019 at 1:49:36 AM UTC-4, Michael Jones wrote:
>
> 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 <bse...@ieee.org <javascript:>>
> wrote:
>
>> On Sat, Jun 8, 2019 at 3:22 PM Michael Ellis <michae...@gmail.com
>> <javascript:>> 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 golan...@googlegroups.com <javascript:>.
>> > 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 golan...@googlegroups.com <javascript:>.
>> 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. jonesmichae...@gmail.com <javascript:>*
>
--
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/354c6790-3657-48b1-90bc-bf9b19114e90%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
