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 <s...@samwhited.com> wrote:
>
>
>
> On September 9, 2018 1:43:09 PM UTC, robert engels <reng...@ix.netcom.com>
> 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.
