Am Tue, 10 Dec 2013 00:26:22 -0800
schrieb Jonathan M Davis <jmdavisp...@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
