Re: [go-nuts] Operator Overloading Implies Generics?

[Michael Jones]

i think the lack of implicit casts makes the idea much better in Go.

I was just thinking of my admiration for goimport sand how nicely that
enriches he programming practice.

if the argument-distinguished function names have the same base name
("MakeCircle$" where $ is one of PointRadius, ThreePoints, ...), and if the
parameter lists are unique, then the same logic the compiler would use to
choose which of the several base-name-only overloaded functions to call can
be lifted from the compiler to an edit-time expander that does name
expansion at the calling site. The programmer can enter MakeCircle(...) but
on save, that will become MakeCircleThreePoints(...). Easy for developer,
clear for all future readers. No change to the language. Think of it as
"continuous govet rewrites"

On Sun, Sep 9, 2018 at 9:54 PM Lucio  wrote:

>
>
> On Sunday, 9 September 2018 15:54:34 UTC+2, Michael Jones wrote:
>>
>>
>> On the down side, if things go wrong, you don't know what source code to
>> go look at. I admit being confused before (C++) as to which overloaded
>> function/method was being called because of default type casts. That is
>> frustrating and can easily be a source of error.
>>
>> Wouldn't the same rules by which embedded structs can have identically
> named elements at different levels, but cannot use them without
> disambiguation, be in some way applicable here?
>
> I'm sure the compiler can flag method signatures that cannot be be
> distinguished. And there are no "default type casts" in Go, are there? I
> thought that was "the law" (constants are slightly different, there, but
> they can be recognised an flagged).
>
> Lucio.
>
> --
> 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.
>


-- 

*Michael T. jonesmichael.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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Operator Overloading Implies Generics?

[Lucio]

On Sunday, 9 September 2018 15:54:34 UTC+2, Michael Jones wrote:
>
>
> On the down side, if things go wrong, you don't know what source code to 
> go look at. I admit being confused before (C++) as to which overloaded 
> function/method was being called because of default type casts. That is 
> frustrating and can easily be a source of error.
>
> Wouldn't the same rules by which embedded structs can have identically 
named elements at different levels, but cannot use them without 
disambiguation, be in some way applicable here?

I'm sure the compiler can flag method signatures that cannot be be 
distinguished. And there are no "default type casts" in Go, are there? I 
thought that was "the law" (constants are slightly different, there, but 
they can be recognised an flagged).

Lucio.

-- 
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.

Re: [go-nuts] Operator Overloading Implies Generics?

[robert engels]

I think that is a small matter, and the compiler could easily prevent these 
overlapping method signatures. I think you rarely have that anyway in well 
designed code, because you don’t need the single parameter version, as the 
multiple parameter version also covers the single parameter case, but even with 
Java it is not ambiguous, as the JLS states it will use the most specific 
method possible, so the single parameter one when only a single parameter is 
passed.

> On Sep 9, 2018, at 10:37 AM, Sam Whited  wrote:
> 
> 
> 
> On September 9, 2018 1:43:09 PM UTC, robert engels  
> wrote:
>> I think the lack of method overload is a poor choice.
>> 
>> …
>> 
>> I would much rather write
>> 
>> NewCircle([]Point)
>> NewCircle(center Point,radius int)
>> 
>> than
>> 
>> NewCircleFromPoints
>> NewCircleFromCenterWithRadius
>> 
>> and this is just a very simple example.
> 
> 
> Allowing this would also open us up to a lot of Java-like ambiguity:
> 
> 
> func Foo(i int) {…}
> func Foo(i ...int) {…}
> 
> Foo(1) // Which function signature does this match?
> 
> —Sam
> 
> -- 
> 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.

-- 
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.

Re: [go-nuts] Operator Overloading Implies Generics?

[Sam Whited]

On September 9, 2018 1:43:09 PM UTC, robert engels  
wrote:
>I think the lack of method overload is a poor choice.
>
> …
>
>I would much rather write
>
>NewCircle([]Point)
>NewCircle(center Point,radius int)
>
>than
>
>NewCircleFromPoints
>NewCircleFromCenterWithRadius
>
>and this is just a very simple example.


Allowing this would also open us up to a lot of Java-like ambiguity:


func Foo(i int) {…}
func Foo(i ...int) {…}

Foo(1) // Which function signature does this match?

—Sam

-- 
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.

Re: [go-nuts] Operator Overloading Implies Generics?

[robert engels]

I don’t see how that works - the details struct would need to be very complex, 
and the NewCircle would need to figure out which method the caller is intended 
(e.g. is the points nil, then the user must want to do center and radius) - 
very error prone too IWT.

> On Sep 9, 2018, at 8:54 AM, Michael Jones  wrote:
> 
> It is a good example of good and bad.
> 
> NewCircle(details)
> 
> is conceptually optimal. Everyone knows what is intended, and it is easier to 
> type.
> 
> On the down side, if things go wrong, you don't know what source code to go 
> look at. I admit being confused before (C++) as to which overloaded 
> function/method was being called because of default type casts. That is 
> frustrating and can easily be a source of error.
> 
> One half-way approach would be tooling. Imasine an editor that, like auto 
> imports was able to auto disambiguate in just these cases.
> 
> 
> 
> On Sun, Sep 9, 2018 at 6:43 AM robert engels  > wrote:
> I think the lack of method overload is a poor choice. A simple review of the 
> stdlib shows a lot of XFromInt XFromUnit and that is workable, but when you 
> have complex structs as parameters, then the naming because really long… and 
> the fact that you don’t have file level hiding, means even for local 
> structures this is a problem across the package.
> 
> I would much rather write
> 
> NewCircle([]Point)
> NewCircle(center Point,radius int)
> 
> than
> 
> NewCircleFromPoints
> NewCircleFromCenterWithRadius
> 
> and this is just a very simple example.
> 
> > On Sep 9, 2018, at 7:45 AM, Ian Lance Taylor  > > wrote:
> > 
> > On Sat, Sep 8, 2018 at 6:58 PM, Rick
> >  > > wrote:
> > 
> > [ replacing "operator" by "method" since that seems to be what was intended 
> > ]
> > 
> >> Is support for [method] overloading implied by support for generics?
> > 
> > No.
> > 
> >> Is it > possible to have one with the other?
> > 
> > Yes, they are entirely independent.
> > 
> >> To be honest, I've been more bothered
> >> by the lack of [method] overloading than by the absence of generics. And (I
> >> assume) no new syntax would be required to support overloading. Or would
> >> there?
> > 
> > I don't think any new syntax would be required.  But there is no
> > serious proposal on the table for method overloading, and the language
> > made an explicit decision on the matter early on:
> > https://golang.org/doc/faq#overloading 
> >  .  Not that we could never
> > change it, but it would need a very strong argument.
> > 
> > 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 
> > .
> 
> -- 
> 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 
> .
> 
> 
> -- 
> Michael T. Jones
> 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 
> .
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Operator Overloading Implies Generics?

[Michael Jones]

It is a good example of good and bad.

NewCircle(details)

is conceptually optimal. Everyone knows what is intended, and it is easier
to type.

On the down side, if things go wrong, you don't know what source code to go
look at. I admit being confused before (C++) as to which overloaded
function/method was being called because of default type casts. That is
frustrating and can easily be a source of error.

One half-way approach would be tooling. Imasine an editor that, like auto
imports was able to auto disambiguate in just these cases.



On Sun, Sep 9, 2018 at 6:43 AM robert engels  wrote:

> I think the lack of method overload is a poor choice. A simple review of
> the stdlib shows a lot of XFromInt XFromUnit and that is workable, but when
> you have complex structs as parameters, then the naming because really
> long… and the fact that you don’t have file level hiding, means even for
> local structures this is a problem across the package.
>
> I would much rather write
>
> NewCircle([]Point)
> NewCircle(center Point,radius int)
>
> than
>
> NewCircleFromPoints
> NewCircleFromCenterWithRadius
>
> and this is just a very simple example.
>
> > On Sep 9, 2018, at 7:45 AM, Ian Lance Taylor  wrote:
> >
> > On Sat, Sep 8, 2018 at 6:58 PM, Rick
> >  wrote:
> >
> > [ replacing "operator" by "method" since that seems to be what was
> intended ]
> >
> >> Is support for [method] overloading implied by support for generics?
> >
> > No.
> >
> >> Is it > possible to have one with the other?
> >
> > Yes, they are entirely independent.
> >
> >> To be honest, I've been more bothered
> >> by the lack of [method] overloading than by the absence of generics.
> And (I
> >> assume) no new syntax would be required to support overloading. Or would
> >> there?
> >
> > I don't think any new syntax would be required.  But there is no
> > serious proposal on the table for method overloading, and the language
> > made an explicit decision on the matter early on:
> > https://golang.org/doc/faq#overloading .  Not that we could never
> > change it, but it would need a very strong argument.
> >
> > 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.
>
> --
> 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.
>


-- 

*Michael T. jonesmichael.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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Operator Overloading Implies Generics?

[robert engels]

I think the lack of method overload is a poor choice. A simple review of the 
stdlib shows a lot of XFromInt XFromUnit and that is workable, but when you 
have complex structs as parameters, then the naming because really long… and 
the fact that you don’t have file level hiding, means even for local structures 
this is a problem across the package.

I would much rather write

NewCircle([]Point)
NewCircle(center Point,radius int)

than

NewCircleFromPoints
NewCircleFromCenterWithRadius

and this is just a very simple example.

> On Sep 9, 2018, at 7:45 AM, Ian Lance Taylor  wrote:
> 
> On Sat, Sep 8, 2018 at 6:58 PM, Rick
>  wrote:
> 
> [ replacing "operator" by "method" since that seems to be what was intended ]
> 
>> Is support for [method] overloading implied by support for generics?
> 
> No.
> 
>> Is it > possible to have one with the other?
> 
> Yes, they are entirely independent.
> 
>> To be honest, I've been more bothered
>> by the lack of [method] overloading than by the absence of generics. And (I
>> assume) no new syntax would be required to support overloading. Or would
>> there?
> 
> I don't think any new syntax would be required.  But there is no
> serious proposal on the table for method overloading, and the language
> made an explicit decision on the matter early on:
> https://golang.org/doc/faq#overloading .  Not that we could never
> change it, but it would need a very strong argument.
> 
> 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.

-- 
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.

Re: [go-nuts] Operator Overloading Implies Generics?

[Ian Lance Taylor]

On Sat, Sep 8, 2018 at 6:58 PM, Rick
 wrote:

[ replacing "operator" by "method" since that seems to be what was intended ]

> Is support for [method] overloading implied by support for generics?

No.

> Is it > possible to have one with the other?

Yes, they are entirely independent.

> To be honest, I've been more bothered
> by the lack of [method] overloading than by the absence of generics. And (I
> assume) no new syntax would be required to support overloading. Or would
> there?

I don't think any new syntax would be required.  But there is no
serious proposal on the table for method overloading, and the language
made an explicit decision on the matter early on:
https://golang.org/doc/faq#overloading .  Not that we could never
change it, but it would need a very strong argument.

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.

Re: [go-nuts] Operator Overloading Implies Generics?

[Tyler Compton]

I believe what you're discussing in this case is function or method
overloading. Operator overloading refers to the ability to specify custom
behavior for operators like +, -, etc.

On Sat, Sep 8, 2018 at 6:58 PM Rick 
wrote:

> With recent discussion concerning the possible introduction of generics in
> Go 2, it occurs to me to ask about support for operator overloading in Go
> 2. By this I mean support for functions having the same name but different
> signature:
>
> func foo(x int) int ...
>
> func foo(x string) bool ...
>
> func foo(x int, y string) ...
>
> etc.
>
> Is support for operator overloading implied by support for generics? Is it
> possible to have one with the other? To be honest, I've been more bothered
> by the lack of operator overloading than by the absence of generics. And (I
> assume) no new syntax would be required to support overloading. Or would
> there?
>
>
> --
> 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.
>

-- 
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.

[go-nuts] Operator Overloading Implies Generics?

[Rick]

With recent discussion concerning the possible introduction of generics in 
Go 2, it occurs to me to ask about support for operator overloading in Go 
2. By this I mean support for functions having the same name but different 
signature:

func foo(x int) int ...

func foo(x string) bool ...

func foo(x int, y string) ...

etc.

Is support for operator overloading implied by support for generics? Is it 
possible to have one with the other? To be honest, I've been more bothered 
by the lack of operator overloading than by the absence of generics. And (I 
assume) no new syntax would be required to support overloading. Or would 
there?


-- 
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.