Re: [Emacs-diffs] trunk r114593: * lisp.h (eassert): Don't use 'assume'.

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 11 Oct 2013 01:19:21 -0700
> From: Daniel Colascione <dancol@dancol.org>
> CC: eggert@cs.ucla.edu, emacs-devel@gnu.org
> 
> On 10/11/13 1:08 AM, Eli Zaretskii wrote:
> > Let me rephrase: assertions are used in unoptimized code, and compile
> > to nothing in optimized code.  'assume' is not needed in unoptimized
> > code, since that code is grossly inefficient anyway.  Thus, it sounds
> > like the two are almost perfectly orthogonal
> 
> Say we have this function:
> 
> void foo (int *a, int *b) { *a = *a / *b; }
> 
> Suppose it's part of foo's contract that it never be called with *b == 
> 0.  In checked builds, we add an assertion to catch callers that violate 
> the contract:
> 
> void foo (int *a, int *b) { eassert (*b != 0); *a = *a / *b; }
> 
> Now suppose we also want the optimizer to take advantage of the fact 
> that *b != 0.

That is a hypothetical situation.  In Emacs, the code is already
written on the assumption that *b != 0, so it is already "optimized"
for that.  In most cases, you won't see any code that can be optimized
out using this assumption, as the programmer already did that --
that's why she added the assertion in the first place.

IOW, assertions in Emacs code are in places where the programmer
_thinks_ something must be true, and writes code based on that
assumption, but she isn't really 100% sure that something to be true.
So the assertion is left behind to catch the cases which the
programmer missed because of her misconceptions.

You are obviously thinking about a different reason of using
assertions: to assert certain invariants in the code and enforce
contracts of certain APIs.  But that is almost never the case in
Emacs, because (gasp!) almost every Emacs API has no well-defined
contract at all!

> > , and lumping them
> > together into a single construct is likely to continue bumping upon
> > problems that stem from basic incompatibility between the use cases,
> > which target two different non-overlapping build types.
> 
> Only when we have side effects.

For now, yes.  I'm afraid that's just the tip of the iceberg, though.

> Looking through the code just now, I only saw a few assertions that
> weren't obviously free of side effects.

The problem is to make sure an assertion obviously _is_ free of side
effects.  With Emacs's massive use of macros, which call other macros,
which call other macros, which... -- that is extremely hard.  And why
should a programmer who just wants to assert something go to such
great lengths?  That is just a maintenance burden for which I find no
good justification.

> > IOW, you should almost _never_ need to use 'assume' where you use
> > 'eassert', and vice versa.  So why do we need a single macro that does
> > both?
> 
> I'd actually argue that you should almost always combine assert and 
> assume.

Not in Emacs, IMO.