I think you just brushed over my entire concern with respect to libraries, and very likely the standard library its self.<div>I've also made what I consider to be reasonable counter arguments to those points in earlier posts, so I won't repeat myself.</div>
<div><br></div><div>I think it's fairly safe to say though, with respect to Don's question, using a tie-breaker is extremely controversial. I can't see any way that could be unanimously considered a good idea.</div>
<div>I stand by the call to ban implicit conversion between float/int. Some might consider that a minor annoyance, but it also has so many potential advantages and time savers down the line too.</div><div><br><div class="gmail_quote">
On 20 October 2011 22:21, Jonathan M Davis <span dir="ltr"><<a href="mailto:jmdavisProg@gmx.com">jmdavisProg@gmx.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Thursday, October 20, 2011 21:52:32 Manu wrote:<br>
> On 20 October 2011 17:28, Simen Kjaeraas <<a href="mailto:simen.kjaras@gmail.com">simen.kjaras@gmail.com</a>> wrote:<br>
> > On Thu, 20 Oct 2011 15:54:48 +0200, Manu <<a href="mailto:turkeyman@gmail.com">turkeyman@gmail.com</a>> wrote:<br>
> >  I could only support 2 if it chooses 'float', the highest performance<br>
> ><br>
> >> version on all architectures AND actually available on all<br>
> >> architectures; given this is meant to be a systems programming<br>
> >> language, and supporting as<br>
> >> many architectures as possible?<br>
> ><br>
> > D specifically supports double (as a 64-bit float), regardless of the<br>
> > actual hardware. Also, the D way is to make the correct way simple, the<br>
> > fast way possible. This is clearly in favor of not using float, which<br>
> > *would* lead to precision loss.<br>
><br>
> Correct, on all architectures I'm aware of that don't have hardware double<br>
> support, double is emulated, and that is EXTREMELY slow.<br>
> I can't imagine any case where causing implicit (hidden) emulation of<br>
> unsupported hardware should be considered 'correct', and therefore made<br>
> easy.<br>
<br>
</div>Correctness has _nothing_ to do with efficiency. It has to do with the result<br>
that you get. Losing precision means that your code is less correct.<br>
<div class="im"><br>
> The reason I'm so concerned about this, is not for what I may or may not do<br>
> in my code, I'm likely to be careful, but imagine some cool library that I<br>
> want to make use of... some programmer has gone and written 'x = sqrt(2)'<br>
> in this library somewhere; they don't require double precision, but it was<br>
> implicitly used regardless of their intent. Now I can't use that library in<br>
> my project.<br>
> Any library that wasn't written with the intent of use in embedded systems<br>
> in mind, that happens to omit all of 2 characters from their float literal,<br>
> can no longer be used in my project. This makes me sad.<br>
><br>
> I'd also like you to ask yourself realistically, of all the integers you've<br>
> EVER cast to/from a float, how many have ever been a big/huge number? And<br>
> if/when that occurred, what did you do with it? Was the precision<br>
> important? Was it important enough to you to explicitly state the cast?<br>
> The moment you use it in a mathematical operation you are likely throwing<br>
> away a bunch of precision anyway, especially for the complex functions like<br>
> sqrt/log/etc in question.<br>
<br>
</div>When dealing with math functions like this, it doesn't really matter whether<br>
the number being passed in is a large one or not. It matters what you want for<br>
the return type. And the higher the precision, the more correct the result, so<br>
there are a lot of people who would want the result to be real, rather than<br>
float or double. It's when your concern is efficiency that you start worrying<br>
about whether a float would be better. And yes, efficiency matters, but if<br>
efficiency matters, then you can always tell it 2.0f instead of 2. Don's<br>
suggestion results in the code being more correct in the general case and yet<br>
still lets you easily make it more efficient if you want. That's very much the D<br>
way of doing things.<br>
<br>
Personally, I'm very leery of making an int literal implicitly convert to a<br>
double when there's ambiguity (e.g. if the function could also take a float),<br>
because then the compiler is resolving ambiguity for you rather than letting<br>
you do it. It risks function hijacking (at least in the sense that you don't<br>
necessarily end up calling the function that you mean to; it's not an issue<br>
for sqrt, but it could matter a lot for a function that has different behavior<br>
for float and double). And that sort of thing is very much _not_ the D way.<br>
<br>
So, I'm all for integers implicitly converting to double so long as there's no<br>
ambiguity. But in any case where there's ambiguity or a narrowing conversion,<br>
a cast should be required.<br>
<font color="#888888"><br>
- Jonathan M Davis<br>
</font></blockquote></div><br></div>