sqrt(2) must go

[Manu]

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" <sandford at jhu.edu> wrote:
>
> On Fri, 21 Oct 2011 09:00:48 -0400, Manu <turkeyman at gmail.com> wrote:
>>
>> On 21 October 2011 10:53, Manu <turkeyman at gmail.com> wrote:
>>>
>>> On 21 October 2011 09:00, Don <nospam at 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! :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20111022/4cfcb97a/attachment-0001.html>