Numeric limits tracking

Manu turkeyman at gmail.com
Sun May 12 21:25:33 PDT 2013


On 13 May 2013 13:46, Walter Bright <newshound2 at digitalmars.com> wrote:

> On 5/12/2013 6:23 PM, Manu wrote:
>
>> It is done by the optimiser, but I'm suggesting that it doesn't only have
>> value
>> in terms of optimisation. It could improve language usability if
>> performed in
>> the front end.
>>
>
> I understand.
>
>
>  In that context, unless the analysis is very powerful(/mature) and can
>> statically determine 'expr', then x would need to be relaxed to unlimited
>> at
>> that point, since it obviously can't know the limits within (or after)
>> that loop.
>> In this case, the compiler would complain that it can't determine x and
>> you
>> would need an explicit cast as usual.
>>
>> I can see the effective forward reference issue here, which could be
>> addressed
>> in time, but even just reasonably simple limits tracking (ie, within
>> sequential
>> code) would make a massive difference. I think programmers would
>> intuitively
>> understand this situation and wouldn't expect magic from the compiler.
>> The places where it matters the most are places where it's dead obvious
>> what the
>> numeric limits are, and it should be equally obvious to the compiler.
>>
>> It's the sort of thing that could be improved with time, but even a very
>> simple
>> start would be a big help in many cases.
>>
>
> It's true you could do a sequential only, very conservative form of data
> flow analysis.
>
> But be aware there are other problems, such as:
>
>   int *p = ...;
>   ...
>   x &= 0xFFFF;
>   ++(*p);      // hmm, is x affected?
>   short s = x;
>

Yes indeed, there are certainly many ways to interfere with it, but I
certainly hope that most lines of code you deal with on a daily basis
aren't like this ;)
Obviously it would grow in maturity over time. In that example, just revert
to unlimited assumptions when it encounters the pointer operation. Limits
may then be refined again in following code.
I can imagine things like proper escaping analysis as planned could
eventually help in cases like this.

Anyway, it's just something to think about. I think it would offer
additional safety/correctness to the language; anywhere you type a blind
cast, you are potentially hiding a future bug. I'd rather never cast when I
don't absolutely need/intend to.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130513/d08d2373/attachment-0001.html>


More information about the Digitalmars-d mailing list