Thread overview | |||||||
---|---|---|---|---|---|---|---|
|
April 21, 2003 unintuitive parameter matching conflict | ||||
---|---|---|---|---|
| ||||
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 |
April 22, 2003 Re: unintuitive parameter matching conflict | ||||
---|---|---|---|---|
| ||||
Posted in reply to Helmut Leitner | "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. |
April 22, 2003 Re: unintuitive parameter matching conflict | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | 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 |
April 22, 2003 Re: unintuitive parameter matching conflict | ||||
---|---|---|---|---|
| ||||
Posted in reply to Helmut Leitner | 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 |
April 22, 2003 Re: unintuitive parameter matching conflict | ||||
---|---|---|---|---|
| ||||
Posted in reply to Helmut Leitner | 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 |
Copyright © 1999-2021 by the D Language Foundation