sqrt(2) must go

[Jonathan M Davis]

On Thursday, October 20, 2011 21:44:05 Don wrote:
> On 20.10.2011 19:28, Jonathan M Davis wrote:
> > On Thursday, October 20, 2011 05:13 Don wrote:
> >> Personally, I'd rather completely eliminate implicit conversions
> >> between
> >> integers and floating point types. But that's just me.
> > 
> > If it's a narrowing conversion, it should require a cast. If it's not,
> > and there's no ambguity in the conversion, then I don't see any problem
> > with allowing the conversion to be implicit. But then again, I deal
> > with floating point values relatively rarely, so maybe there's
> > something that I'm missing.> 
> >> My proposal was effectively: if it's ambiguous, choose double. That's
> >> all.> 
> > Are there _any_ cases in D right now where the compiler doesn't error
> > out on ambiguity? In all of the cases that I can think of, D chooses to
> > give an error on ambiguity rather than making a choice for you. I'm all
> > for an int literal being implicitly converted to a double if the
> > function call is unambiguous and there's no loss of precision.
> 
> The problem is, the existing approach will break a lot of existing code.
> For example, std.math.log(2) currently compiles. But, once the overload
> log(double) is added, which *must* happen, that code will break.
> Note that there is no realistic deprecation option, either. When the
> overload is added, code will break immediately.
> If we continue with this approach, we have to accept that EVERY TIME we
> add a floating point overload, existing code will break.
> 
> So, we either make accept that; or we make everything that will ever
> break, break now (accepting that some stuff _will_ break, that would
> never have broken); or we introduce a tie-breaker rule.
> 
> The question we face is really, which is the lesser evil?
> 
>  > But if there's any ambiguity, then it's
>  > definitely against the D way to have the compiler pick for you.
> 
> Explain why this compiles:
> 
> void foo(ubyte x) {}
> void foo(short x) {}
> void foo(ushort x) {}
> void foo(int x) {}
> void foo(uint x) {}
> void foo(long x) {}
> void foo(ulong x) {}
> 
> void main()
> {
>     byte b = -1;
>     foo(b); // How ambiguous can you get?????
> }

I wouldn't have expected that to compile. If we're already doing ambiguous 
implicit casts like this, then implicitly casting an int to a double isn't 
really going to make this much worse. On the bright side, it's almost 
certainly bad practice to have a function which takes a float and a double do 
something drastically different, so the ambiguity isn't likely to cause 
problems. But since D usually doesn't compile with ambiguities (particularly 
with classes), I'm surprised that it's as lax as it is with integral values.

- Jonathan M Davis