<p>It would still allow function hijacking.<br>
void func(double v); exists...<br>
func(2);<br>
then someone comes along and adds func(float v); .. It will now hijack the call.<br>
That's what you mean right?</p>
<p>On Oct 22, 2011 1:45 AM, "Robert Jacques" <<a href="mailto:sandford@jhu.edu">sandford@jhu.edu</a>> wrote:<br>
><br>
> On Fri, 21 Oct 2011 09:00:48 -0400, Manu <<a href="mailto:turkeyman@gmail.com">turkeyman@gmail.com</a>> wrote:<br>
>><br>
>> On 21 October 2011 10:53, Manu <<a href="mailto:turkeyman@gmail.com">turkeyman@gmail.com</a>> wrote:<br>
>>><br>
>>> On 21 October 2011 09:00, Don <<a href="mailto:nospam@nospam.com">nospam@nospam.com</a>> wrote:<br>
><br>
> [snip]<br>
><br>
>>> 1: Seems reasonable for literals; "Integer literals and expressions should<br>
>>> use range propagation to use<br>
>>> the thinnest loss-less conversion"... but can you clarify what you mean by<br>
>>> 'expressions'? I assume we're talking strictly literal expressions?<br>
><br>
><br>
> Consider sqrt(i % 10). No matter what i is, the range of i % 10 is 0-9.<br>
><br>
> I was more thinking of whether plain old assignment would be allowed:<br>
><br>
> float f = myshort;<br>
><br>
> Of course, if we deny implicit conversion, shouldn't the following fail to compile?<br>
><br>
> float position = index * resolution;<br>
><br>
><br>
>>> 2b: Does runtime bounds checking actually addresses the question; which of<br>
>>> an ambiguous function to choose?<br>
>>> If I read you correctly, 2b suggests bounds checking the implicit cast for<br>
>>> data loss at runtime, but which to choose? float/double/real? We'll still<br>
>>> arguing that question even with this proposal taken into consideration... :/<br>
>>> Perhaps I missed something?<br>
><br>
><br>
> Yes, nut only because I didn't include it. I was thinking of<br>
><br>
> float f = i;<br>
><br>
> as opposed to<br>
><br>
> func(i)<br>
><br>
> for some reason. Bounds checking would only make sense if func(float) was the only overload.<br>
><br>
>>> Naturally all this complexity assumes we go with the tie-breaker approach,<br>
>>> which I'm becoming more and more convinced is a bad plan...<br>
>>><br>
>><br>
>> Then again, with regards to 1, the function chosen will depend on the<br>
>> magnitude of the int, perhaps a foreign constant, you might not clearly be<br>
>> able to know which one is called... What if the ambiguous overloads don't<br>
>> actually perform identical functionality with just different precision? ..<br>
><br>
><br>
> Then whoever wrote the library was Evil(tm). Given that these rules wouldn't interfere with function hijacking, I'm not sure of the practicality of this concern. Do you have an example?<br>
><br>
><br>
>> I don't like the idea of it being uncertain.<br>
>><br>
>> And one more thing to ponder, is the return type telling here?<br>
>> float x = sqrt(2);<br>
>> Obviously this may only work for these pure maths functions where the<br>
>> return type is matched to the args, but maybe it's an element worth<br>
>> considering.<br>
>> ie, if the function parameter is ambiguous, check for disambiguation via<br>
>> the return type...? Sounds pretty nasty! :)<br>
</p>