www.digitalmars.com         C & C++   DMDScript  

D - unintuitive parameter matching conflict

reply 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
Apr 21 2003
parent reply "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.
Apr 22 2003
parent reply 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
Apr 22 2003
next sibling parent "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
Apr 22 2003
prev sibling parent "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
Apr 22 2003