checkedint call removal

Timon Gehr via Digitalmars-d digitalmars-d at puremagic.com
Fri Aug 1 08:28:58 PDT 2014


On 08/01/2014 01:53 PM, Don wrote:
> On Friday, 1 August 2014 at 09:02:36 UTC, Walter Bright wrote:
>> On 7/31/2014 11:24 PM, "Ola Fosheim Grøstad"
>> <ola.fosheim.grostad+dlang at gmail.com>" wrote:
>>> On Friday, 1 August 2014 at 02:44:51 UTC, Walter Bright wrote:
>>>>> That entry makes no mention of assert being used as an optimization
>>>>> hint.
>>>>>
>>>> Saying that a predicate is always true means it's available to the
>>>> optimizer.
>>>
>>> An assert does not say that the predicate is always true.
>>
>> Yes, it does. From Meyers' comprehensive tome on the topic
>> "Object-Oriented Software Construction" (1997) where he writes:
>>
>> "A run-time assertion violation is the manifestation of a bug in the
>> software."
>>
>>     -- pg. 346
>>
>> In fact, Meyers calls it "rule (1)" of assertions.
>
> I would rephrase it as: "An assert says that either the predicate
> is always true, or else the program is in an invalid state and will not
> operate correctly".
> ...

Bertrand _Meyer_ is not a furious proponent of undefined behaviour. He 
is not exactly a fan of C or C++ either and an expressed opponent of the 
typical 'C hacker' attitude.

> But I do think this entire argument seems to me to be rather misplaced.
> I think it's really it's about -release, not about assert().
>
> The arguments presented by Ola et al mostly seem to be arguments against
> the use of the -release switch. Because it is a very dangerous flag.
>
> If you're removing all your asserts I'd say you're playing a dangerous
> game already.

Sure, and it is /obviously/ perfectly fine to e.g. kill a tightrope 
walker, so this should not be prosecuted.

> If an assert would have failed, but execution continued
> anyway, you're in undefined behaviour

No. For the purpose of (maybe remote!) debugging, the programmer wants 
the behaviour to be _the one that the program specifies_, even if it is 
not the one that he _expected_.

> -- at the very least, you're in a
> condition that the programmer believed could never happen.
> ...

Yes, a condition that _some_ programmer believed could never happen. It 
is not even a given that this condition is not actually created 
somewhere and handled somewhere else, especially as software evolves.

> If you are disabling your asserts, but still believe that they may fail,
> that means you're expecting your program to enter undefined behaviour!

Nonsense. This claim is ignoring the current reality of software 
development. One would be expecting one's program to be buggy, but one 
would still think that _almost all_ assertions pass always and those 
that don't would be expected to pass _almost always_. How many pieces of 
non-trivial bug-free software did you write or _were required to work on 
without full knowledge about the code base_?

In any case if one is _disabling_ one's asserts, one doesn't expect them 
to have any kind of effect whether they may fail or not.

> That seems to be a rather illogical position.
>

It was constructed to seem to be. For example, the expectation that some 
asserts are wrong was conveniently replaced by the expectation that all 
(or at least a murkily unspecified amount of) asserts are wrong and the 
existence of trade-offs was ignored. This is simply a straw man used to 
defend an indefensible position.

> I think very strongly that we should rename the "-release" switch,
> especially if we do start to make use of asserts. It's going to cause no
> end of confusion and passionate debate.
>
> ---

Disabling assertions and contracts and using them for optimization 
should be distinct options.

>
> In one of the 2013 DConf talks a lint tool was discussed that disallowed
> you from you writing a condition that was provably impossible based on
> 'in' contracts.
> eg:
>
> void foo( int x)
> in{
>     assert(x > 6);
> }
> body {
>      if (x > 2)   // ERROR! This is always true!
>      ...
> }
>
> Which is an interesting approach.
>
> By definition, any optimisations that are performed on the basis of an
> assert() that could affect control flow, are detectable with 100%
> accuracy by a lint tool.

By a family of lint tools indexed by the respective compiler back-ends. 
Furthermore, you have to understand all of those back-ends and all their 
passes completely and you need to track how information relating 
possible optimizations flows through them. You will not write all those 
lints in a lifetime and you need to start this undertaking again 
whenever someone writes a new back-end and you need to always keep the 
lints in sync with the back-ends (and maybe, front-ends). Besides, it is 
an incredibly complex solution for a completely trivial issue.

> And so, if you wanted to remove all your
> asserts but were worried about this issue, it's detectable at compile time.
>

This issue does not only affect people who are worried about it (and I'd 
guess the truth is way closer to the opposite), and in fact you yourself 
claimed above that it only affects people who are not worried about 
undefined behaviour. This is a rather illogical position to be in, even 
if both of the contradicting claims are not true statements. (Sorry! 
Couldn't resist! :-) )

In any case, please don't ignore existing complexity in order to make 
claims that seem pragmatic.


More information about the Digitalmars-d mailing list