The following code won't compile because of "function sq overloads double(double x) and int(int x) both match argument list for sq"

    double sq(double x) {
        return x*x;
    }
    int sq(int x) {
        return x*x;
    }
    int main (char [][] args)
    {
        float y=3.14;
        double z=sq(y);
        return 0;
    }

I think the compiler should have a clear matching strategy and match float to double (match any primitive according to clear preferences if an exact match is missing).


--
Helmut Leitner    leitner@hls.via.at Graz, Austria   www.hls-software.com

"Helmut Leitner" <helmut.leitner@chello.at> wrote in message news:3EA430C3.FC94DF42@chello.at...
> The following code won't compile because of
> "function sq overloads double(double x) and int(int x) both match argument
list for sq"
>
>     double sq(double x) {
>         return x*x;
>     }
>     int sq(int x) {
>         return x*x;
>     }
>     int main (char [][] args)
>     {
>         float y=3.14;
>         double z=sq(y);
>         return 0;
>     }
>
> I think the compiler should have a clear matching strategy and match float
to double
> (match any primitive according to clear preferences if an exact match is
missing).

The matching strategy with D is one of:

1) exact match
2) match with conversions
3) no match

D deliberately does not do shades of preferences within (2). Although there are many cases where it looks like a good idea, the end result of that is the numbing complexity of the C++ overload rules.

Walter wrote:
> 
> 1) exact match
> 2) match with conversions
> 3) no match
> 
> D deliberately does not do shades of preferences within (2). Although there are many cases where it looks like a good idea, the end result of that is the numbing complexity of the C++ overload rules.

I wouldn't see much complexity in a single level of preference

   char => int
   wchar => int
   bit => int
   byte => int
   short => int

   ubyte => uint
   ushort => uint

   int => long

   uint => ulong

   float => double
   real => double

   ifloat => cdouble
   idouble => cdouble
   cfloat => cdouble
   ireal => cdouble
   creal => cdouble

in case that an exact match is not available.

So one could do with 6 interfaces instead of 16 (in most cases) without forcing the users of an API to use lots of casts.

-- 
Helmut Leitner    leitner@hls.via.at
Graz, Austria   www.hls-software.com

Otherwise we have to provide overloads for *EVERY SINGLE D TYPE*.  Of which there are MANY.  Especially now that there are ifloat/idouble/ireal/cfloat/cdouble/creal.

Maybe we could declare one single function to be able to take a range of types.

template (class F:<numeric)
F sq(F x) {
        return x*x;
    }

Sean

"Helmut Leitner" <leitner@hls.via.at> wrote in message news:3EA56A6E.27410F52@hls.via.at...
>
>
> Walter wrote:
> >
> > 1) exact match
> > 2) match with conversions
> > 3) no match
> >
> > D deliberately does not do shades of preferences within (2). Although
there
> > are many cases where it looks like a good idea, the end result of that
is
> > the numbing complexity of the C++ overload rules.
>
> I wouldn't see much complexity in a single level of preference
>
>    char => int
>    wchar => int
>    bit => int
>    byte => int
>    short => int
>
>    ubyte => uint
>    ushort => uint
>
>    int => long
>
>    uint => ulong
>
>    float => double
>    real => double
>
>    ifloat => cdouble
>    idouble => cdouble
>    cfloat => cdouble
>    ireal => cdouble
>    creal => cdouble
>
> in case that an exact match is not available.
>
> So one could do with 6 interfaces instead of 16 (in most cases) without forcing the users of an API to use lots of casts.
>
> --
> Helmut Leitner    leitner@hls.via.at
> Graz, Austria   www.hls-software.com

Please no! Walter has made the right decision here.

"Helmut Leitner" <leitner@hls.via.at> wrote in message news:3EA56A6E.27410F52@hls.via.at...
>
>
> Walter wrote:
> >
> > 1) exact match
> > 2) match with conversions
> > 3) no match
> >
> > D deliberately does not do shades of preferences within (2). Although
there
> > are many cases where it looks like a good idea, the end result of that
is
> > the numbing complexity of the C++ overload rules.
>
> I wouldn't see much complexity in a single level of preference
>
>    char => int
>    wchar => int
>    bit => int
>    byte => int
>    short => int
>
>    ubyte => uint
>    ushort => uint
>
>    int => long
>
>    uint => ulong
>
>    float => double
>    real => double
>
>    ifloat => cdouble
>    idouble => cdouble
>    cfloat => cdouble
>    ireal => cdouble
>    creal => cdouble
>
> in case that an exact match is not available.
>
> So one could do with 6 interfaces instead of 16 (in most cases) without forcing the users of an API to use lots of casts.
>
> --
> Helmut Leitner    leitner@hls.via.at
> Graz, Austria   www.hls-software.com