On Thu, 30 Dec 2010 14:34:45 -0600
Andrei Alexandrescu <[email protected]> wrote:
> >> Then people probably need to use sqrt(2.0) or sqrt(cast(double)2).
> >
> > I've got a lot of sympathy for the first alternative (absolutely NONE
> > for the second!). But unfortunately, the language allows sqrt(2) to
> > compile if there is only a single sqrt function.
> > We have here a feature which works in some cases, but not in others.
>
> I agree there's an issue here, but not only with floating point numbers:
>
> void fun(long);
> void fun(ulong);
> ...
> fun(2); // whaa?
>
> The same problem is at work here: 2 is an int and is equally inclined to
> go to either long or ulong.
>
> Generally I find it a bit difficult to integrate this proposal within
> the conversions framework that we have; it adds an entire new concept
> into the mix. This makes me be more conservative. For literals, all
> things considered, I don't think requiring the .0 is a major hindrance.
> For non-literals that's more of an issue:
>
> int x = 42;
> sqrt(x); // whaa?
>
> I'm not sure to what extent this is a problem; I defer that opinion to
> Don. If this is indeed an important issue, we should address it. If not,
> I think improving the situation for literals exclusively would provide
> only marginal benefit.
Here is the fool man's solution: rather strict.
Context: a func expects a parameter of a given (numeric) type (including
chars!).
* If a typed thingie (read: a var) is passed, then it must have the given type,
or a type that does not carry any semantic difference. By this, I mean eg int
for long (the diff is purely implementation detail). But uint would be rejected
(for me, uints are conceptually ordinals or cardinal; 'integer' is different
concept).
* If a literal is passed, then it must have a corresponding form, according to:
*char float/dbl unsigned signed
'a' '\u0041' 65.0 65 +65
In other words, in an ambiguous context, the user is requested to provide the
information needed to properly distinguish among possible interpretations. If
sqrt is a float func, then sqrt(2) does not compile, basta! This may provoke
loud cries ;-) But, provided the rule is widely published and we write a
sensible error message, the correction is so easy...
[By the way, I would also have a single numeric type on the implementation side
(except possibly for arbitrary sized ints) and a quartet of plainly conceptual
types on the language side: namely Ordinal Cardinal Integer Real. Yes, my
computer says Fri Dec 31.]
Denis
-- -- -- -- -- -- --
vit esse estrany ☣
spir.wikidot.com
