PROPOSAL: Implicit conversions of integer literals to floating

[spir]

On Thu, 30 Dec 2010 14:34:45 -0600
Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org> 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