checkedint call removal

Paolo Invernizzi via Digitalmars-d digitalmars-d at puremagic.com
Sun Aug 3 02:27:20 PDT 2014


On Saturday, 2 August 2014 at 22:00:27 UTC, Andrew Godfrey wrote:
> On Saturday, 2 August 2014 at 21:36:11 UTC, Tobias Pankrath 
> wrote:
>> On Saturday, 2 August 2014 at 21:25:40 UTC, Ola Fosheim 
>> Grøstad wrote:
>>> On Saturday, 2 August 2014 at 20:27:09 UTC, Andrei 
>>> Alexandrescu wrote:
>>>> Hmmm... code that fails assertions is hardly working. -- 
>>>> Andrei
>>>
>>> It is not the code that fails the assertion, it is the 
>>> asserted proposition that has not be satisfied by the axioms 
>>> in the program as it has been formulated in the context. It 
>>> does not mean "can not be satisfied", but "has not been 
>>> satisfied".
>>
>> Don't you agree, that a program that throws AssertError in non 
>> -release* build is broken?
>>
>> * this is not the opposite of debug
>
> By this definition of 'broken', I assert that most shipped 
> software is broken.

I strongly disagree with that: if there's pressure for a release, 
most software in that condition has the assert _removed_ or 
_commented_, a bug opened, and a boss directive to do so so that 
it's boss responsibility having taken the risk.

The assert is _reinserted_ or _uncommented_ when there's someone 
hunting for that bug after the release.

If this operation can't be done because the failing asserts are a 
bazillion, compiling it in '-release' with the proposed 
assert/assume semantic don't change anything: from time to time, 
when the snowball of failed assert-optimisations will start to 
destroy the program logic, all that thing will explode in the 
face of the user.
---
Paolo


More information about the Digitalmars-d mailing list