d-programming-language.org

[Andrei Alexandrescu]

On 7/4/11 2:48 PM, bearophile wrote:
> Steven Schveighoffer:
>
>> To the point -- lots of existing D and C code uses the properties
>> of integer overflow.  If integer overflow is assumed to be an
>> error, then that code is broken, even though the code *expects*
>> overflow to occur, and in fact might *depend* on it occurring.
>
> In this case you wrap the code in something that allows it to
> overflow without errors, like:
>
> unsafe(overflows) { // code here }

This approach has a number of issues. First, addressing transitivity is
difficult. If the code in such a scope calls a function, either every
function has two versions, or chooses one way to go about it. Each
choice has obvious drawbacks.

Second, programmers are notoriously bad at choosing which code is
affecting bottom line performance, yet this feature explicitly puts the
burden on the coder. So code will be littered with amends, yet still be
overall slower. This feature has very poor scalability.

> ------------------------
>
> Andrei:
>
>> This and others (zero- vs. one-based indexing, closed vs. open
>> intervals etc.) are issues with well-understood tradeoffs that
>> could go either way.<
>
> Integral overflows are not the same thing as indexing and intervals.

Of course they're not the same thing. Commonalities and differences.

> Such last two are equal ways to write the same thing, while overflows
> are a way to spot a class of bugs in code.

Well they also are a solid way to slow down all code.

>> Making a choice in such matters becomes part of a language's
>> ethos.<
>
> Right, and I think D Zen is pro-safety.

You are using a different version of safety than D does. D defines very 
precisely safety as memory safety. Your definition is larger, less 
precise, and more ad-hoc.

>> After a while it becomes clear that rehashing such matters without
>> qualitatively new arguments is futile.<
>
> I have answered because you have said wrong things. You have
> implicitly said that good overflow tests are doable with library
> code, and I have explained why you are wrong. This isn't futile.

Probably one good thing to get past is the attitude that in such a 
discussion the other is "wrong". These are simple matters of which 
understanding does not require any amount of special talent or 
competence. So the first step is to understand that some may actually 
value a different choice with different consequences than yours because 
they find the costs unacceptable. As someone who makes numerous posts 
and bug reports regarding speed of D code, you should definitely have 
more appreciation for that view.


Andrei