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