How about "auto" parameters?

[Timon Gehr]

Andrei Alexandrescu wrote:
> 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.
> [snip.]

Hm ok.
But @compiler: The compiler could just as well insert explicit casts (I think
thats how it deals with implicit casts during semantic analysis anyways.), or am I
missing something?
@Libraries: True, the libraries internal precision does not impact user code. But
if the user stores intermediate results in a type that is too coarse, user code
might inadvertently impact library code in a crippling way. This then reflects
badly on user code. (float a=LibraryFunctionTakingAndReturningReal(123.2); float
c=Ditto(a); // now c is less precise than the library could offer)


Timon