checkedint call removal

Andrew Godfrey via Digitalmars-d digitalmars-d at puremagic.com
Fri Aug 1 23:40:11 PDT 2014


On Saturday, 2 August 2014 at 05:59:14 UTC, Timon Gehr wrote:
> On 08/02/2014 05:34 AM, Andrew Godfrey wrote:
>> Suppose I call some logging function which has a faulty 
>> assertion in it.
>> What about Walter's position prevents that assertion's effects 
>> from
>> escaping the logging function and infecting my code?
>
> Nothing. Undefined behaviour is completely non-modular.
>
>> I know cross-module
>> optimization is hard hence this may be unlikely,
>
> Inlining may happen.
>
>> but still it shows
>> something missing.
>>
>> I know Walter has said repeatedly that at this point the 
>> program is
>> invalid, Implying that it deserves whatever happens to it. I 
>> suspect
>> this is a subtopic we should be discussing more directly. What 
>> are the
>> boundaries?
>
> The semantics that are proposed to be pulled into the language 
> spec are currently summarized as:
>
> - In non-release mode, an assertion failure will abort the 
> program (maybe by throwing an Error).
>
> - In release mode, an assertion failure leads to undefined 
> behaviour.
>
> I.e. I think there aren't any 'boundaries', unless I am 
> misunderstanding this term.

So even if the assertion is incorrect and the code is correct, 
the caller's correctness can be compromised? This seems 
impractical. As in, no one will in good conscience turn it on, 
except when their program is very small.


More information about the Digitalmars-d mailing list