How about "auto" parameters?

Jonathan M Davis jmdavisProg at gmx.com
Tue Jun 7 10:43:43 PDT 2011


On 2011-06-07 10:20, 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
> 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.

Hmmm. That's a bit odd given that narrowing conversion require casts for 
integral types. Casting from an integral type to a floating point type of the 
same size seems fine to me (floating point values aren't exactly exact 
anyway), but I would have thought that narrowing conversions between floating 
point types would have required casts.

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

Yes. But just because a type conversion is safe doesn't mean that it's the 
right thing to do (e.g. narrowing conversions are _always_ safe but often 
incorrect). Casts hide things, and while to does it less, that doesn't mean 
that it doesn't do it. So, it's not like to solves all of the problems that 
you might have with casting. And there are plenty of programmers who will just 
use casts when they should be using to, because casting is the normal thing to 
do in most C-based languages. So, introducing situations where casts are 
required but could reasonably not be can be problematic. The trick is 
determining which implicit casts ultimately make sense and which don't.

- Jonathan M Davis


More information about the Digitalmars-d mailing list