Type inference and overloaded functions

[Marco Leise]

Am Tue, 10 Dec 2013 00:26:22 -0800
schrieb Jonathan M Davis <jmdavisProg at gmx.com>:

> On Tuesday, December 10, 2013 09:00:22 Namespace wrote:
> > I use this implict converting to static arrays very often and if
> > we deprecate it, we really need something to declare static array
> > literals.
> 
> Implicit conversion isn't the problem. It's the fact that there are two 
> possible matches, and it picks one over the other rather than requiring the 
> programmer to indicate which one is correct (e.g. via casting). That's just 
> going to lead to bugs. If there is no conflict, then the implicit conversion is 
> fine. It's just that when there is a conflict that it's a problem.
> 
> We have similar problems with stuff like
> 
> void foo(bool b) {...}
> void foo(long l) {...}
> 
> foo(1); //calls the bool overload
> 
> There was a huge thread on this a while back where almost no one other than 
> Walter thought that this behavior was good, and it was clearly causing bugs 
> (Walter argued that the solution was to just add an overload for int rather 
> than fixing the conversion problem). IMHO, there should be no implicit 
> conversion of literals when there's a conflict. It should result in an 
> ambiguity error so that the programmer has the opportunity to indicate the 
> correct overload.
> 
> - Jonathan M Davis

In the case above, *if* there was an int overload would you
argue for still requiring to use foo(cast(int)1) ? Since that
is what would come out of it when cast(int[3])[1,2,3] is
required. That would hurt the readability of I/O functions
that are specialized for all integral types. EndianStream
comes to mind.

e.g.: stream.write(cast(int)1);

Since cast is a blunt tool, I expect APIs to change away from
overloads entirely and use writeInt, writeUbyte etc. instead.

-- 
Marco