• Helmut Leitner (19/19) Apr 21 2003 The following code won't compile because of
• Walter (12/28) Apr 22 2003 list for sq"
• Helmut Leitner (25/33) Apr 22 2003 I wouldn't see much complexity in a single level of preference
• Sean L. Palmer (14/46) Apr 22 2003 Otherwise we have to provide overloads for *EVERY SINGLE D TYPE*. Of wh...
• Matthew Wilson (5/37) Apr 22 2003 Please no! Walter has made the right decision here.

Helmut Leitner <helmut.leitner chello.at> writes:

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

"Walter" <walter digitalmars.com> writes:

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

Helmut Leitner <leitner hls.via.at> writes:

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

"Sean L. Palmer" <palmer.sean verizon.net> writes:

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

"Matthew Wilson" <matthew stlsoft.org> writes:

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