How about "auto" parameters?

[Andrei Alexandrescu]

On 6/7/11 12:20 PM, Timon Gehr wrote:
>
> 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

I'm a bit weary about these too.

> 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.

I used to think the same but Walter convinced me otherwise. Automatic 
floating point conversions allow the compiler and libraries to store 
intermediate results at the optimal precision without impacting user code.

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

Currently to!T for implicitly-convertible types does not get in the way.


Andrei