Okay so we're thinking of allowing implicit casting now ONLY if it can be guaranteed that the cast is lossless?<div><br></div><div>I don't see how this addresses the original question though, which was how to resolve an ambiguous function selection? It selects the smallest one it will fit into?</div>
<div>Does that mean it will always choose the double version if you pass an int32 without any extra info narrowing its possible bounds?</div><div><br><div class="gmail_quote">On 23 October 2011 22:36, Don <span dir="ltr"><<a href="mailto:nospam@nospam.com">nospam@nospam.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">On 21.10.2011 09:53, Manu wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 21 October 2011 09:00, Don <<a href="mailto:nospam@nospam.com" target="_blank">nospam@nospam.com</a><div class="im"><br>
<mailto:<a href="mailto:nospam@nospam.com" target="_blank">nospam@nospam.com</a>>> wrote:<br>
<br>
On 21.10.2011 05:24, Robert Jacques wrote:<br>
<br>
On Thu, 20 Oct 2011 09:11:27 -0400, Don <<a href="mailto:nospam@nospam.com" target="_blank">nospam@nospam.com</a><br></div><div><div></div><div class="h5">
<mailto:<a href="mailto:nospam@nospam.com" target="_blank">nospam@nospam.com</a>>> wrote:<br>
[snip]<br>
<br>
I'd like to get to the situation where those overloads can<br>
be added<br>
without breaking peoples code. The draconian possibility is<br>
to disallow<br>
them in all cases: integer types never match floating point<br>
function<br>
parameters.<br>
The second possibility is to introduce a tie-breaker rule:<br>
when there's<br>
an ambiguity, choose double.<br>
And a third possibility is to only apply that tie-breaker<br>
rule to<br>
literals.<br>
And the fourth possibility is to keep the language as it is<br>
now, and<br>
allow code to break when overloads get added.<br>
<br>
The one I really, really don't want, is the situation we<br>
have now:<br>
#5: whenever an overload gets added, introduce a hack for that<br>
function...<br>
<br>
<br>
I agree that #5 and #4 not acceptable longer term solutions. I do<br>
CUDA/GPU programming, so I live in a world of floats and ints. So<br>
changing the rules does worries me, but mainly because most<br>
people don't<br>
use floats on a daily basis, which introduces bias into the<br>
discussion.<br>
<br>
<br>
Yeah, that's a valuable perspective.<br>
sqrt(2) is "I don't care what the precision is".<br>
What I get from you and Manu is:<br>
if you're working in a float world, you want float to be the tiebreaker.<br>
Otherwise, you want double (or possibly real!) to be the tiebreaker.<br>
<br>
And therefore, the<br>
<br>
<br>
Thinking it over, here are my suggestions, though I'm not sure<br>
if 2a or<br>
2b would be best:<br>
<br>
1) Integer literals and expressions should use range propagation<br>
to use<br>
the thinnest loss-less conversion. If no loss-less conversion<br>
exists,<br>
then an error is raised. Choosing double as a default is always the<br>
wrong choice for GPUs and most embedded systems.<br>
2a) Lossy variable conversions are disallowed.<br>
2b) Lossy variable conversions undergo bounds checking when<br>
asserts are<br>
turned on.<br>
<br>
<br>
The spec says: "Integer values cannot be implicitly converted to<br>
another type that cannot represent the integer bit pattern after<br>
integral promotion."<br>
Now although that was intended to only apply to integers, it reads<br>
as if it should apply to floating point as well.<br>
<br>
<br>
The idea behind 2b) would be:<br>
<br>
int i = 1;<br>
float f = i; // assert(true);<br>
i = int.max;<br>
f = i; // assert(false);<br>
<br>
<br>
That would be catastrophically slow.<br>
<br>
I wonder how painful disallowing lossy conversions would be.<br>
<br>
<br></div></div>
1: Seems reasonable for literals; "Integer literals and expressions<div class="im"><br>
should use range propagation to use<br></div><div class="im">
the thinnest loss-less conversion"... but can you clarify what you mean<br>
by 'expressions'? I assume we're talking strictly literal expressions?<br>
</div></blockquote>
<br>
Any expression. Just as right now, long converts to int only if the long expression is guaranteed to fit into 32 bits.<br>
Of course, if it's a literal, this is very easy.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2b: Does runtime bounds checking actually addresses the question; which<br>
of an ambiguous function to choose?<br>
If I read you correctly, 2b suggests bounds checking the implicit cast<br>
for data loss at runtime, but which to choose? float/double/real? We'll<br>
still arguing that question even with this proposal taken into<br>
consideration... :/<br>
</blockquote>
<br></div>
It's an independent issue.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Perhaps I missed something?<div class="im"><br>
<br>
Naturally all this complexity assumes we go with the tie-breaker<br>
approach, which I'm becoming more and more convinced is a bad plan...<br>
</div></blockquote>
<br>
No, it doesn't. As I said, this is independent. Except that it does mean that some existing int->float conversions would be disallowed.<br>
EG,<br>
float foo(int x)<br>
{<br>
return x;<br>
}<br>
wouldn't compile, because x might not fit into a float without loss of accuracy.<br>
</blockquote></div><br></div>