How about "auto" parameters?

[Timon Gehr]

Jonathan M Davis wrote:
> ...
> And while D might arguably allow too many implicit conversions, it allows
> fewer than C or C++. I actually would expect that bugs due to implicit
> conversions would be fairly rare in D. And requiring more conversions to be
> explicit might actually make things worse, because it would become more
> frequently necessary to use casts, which tend to hide various types of bugs.
> So, while it might be better to require casting in a few more places than D
> currently does, on the whole it works quite well. And certainly expecting a
> major paradigm shift at this point is unrealistic. Minor improvements may be
> added to the language, and perhaps major backwards-compatible features may be
> added, but for the most part, D is currently in the mode of stabilizing and
> completing the implementation of its existing feature set. It's _far_ too late
> in the game to introduce something like Hindley-Milner type inference,
> regardless of whether it would have been a good idea in the beginning (and
> honestly, given D's C and C++ roots, I very much doubt that it ever would have
> been a good idea to have Hindley-Milner type inference in it - that would have
> made for a _very_ different sort of language, which definitely wouldn't be D).
>
> - Jonathan M Davis


Widening implicit casts are very convenient.
What I think is annoying is that D allows implicit conversions that are narrowing.
Eg:
int -> float
long -> double
real -> double
double -> float

Especially questionable is the real -> double -> float chain. This and implicitly
casting an integer value to a floating point type whose mantissa is too small
should imho be disallowed.

BTW: You can have safe 'casts'. I think std.conv.to does/will allow only type
conversions that are safe.

Timon