assert semantic change proposal

David Bregman via Digitalmars-d digitalmars-d at puremagic.com
Tue Aug 5 21:05:40 PDT 2014


On Wednesday, 6 August 2014 at 01:11:55 UTC, Jeremy Powers via 
Digitalmars-d wrote:
>> That's in the past. This is all about the pros and cons of 
>> changing it now
>> and for the future.
>>
>
> The main argument seems to revolve around whether this is 
> actually a change
> or not.  In my (and others') view, the treatment of assert as 
> 'assume' is
> not a change at all.  It was in there all along, we just needed 
> the wizard
> to tell us.
>

How can there be any question? This is a change in the compiler, 
a change in the docs, change in what your program does, change of 
the very bytes in the executable. If my program worked before and 
doesn't now, how is that not a change? This must be considered a 
change by any reasonable definition of the word change.

I don't think I can take seriously this idea that someone's 
unstated, unmanifested intentions define change more so than 
things that are .. you know.. actual real changes.

Much of the rest of your post seems to be predicated on this, so 
I don't think I can respond to it. Let me know if I missed 
something.

> In an attempt to return this discussion to something useful, 
> question:
>
> If assert means what I think it means (and assuming we agree on 
> what the
> actual two interpretations are), how do we allay concerns about 
> it?  Is
> there anything fundamentally/irretrievably bad if we use this 
> new/old
> definition?

Well I think I outlined the issues in the OP. As for solutions, 
there have been some suggestions in this thread, the simplest is 
to leave things as is and introduce the optimizer hint as a 
separate function, assume().

I don't think there was any argument presented against a separate 
function besides that Walter couldn't see any difference between 
the two behaviors, or the intention thing which doesn't really 
help us here.

I guess the only real argument against it is that pre-existing 
asserts contain significant optimization information that we 
can't afford to not reuse. But this is a claim I'm pretty 
skeptical of. Andrei admitted it's just a hunch at this point. 
Try looking through your code base to see how many asserts would 
be useful for optimizing. For me, it's mostly 
default:assert(false); in switch statements, though ironically 
that is defined to produce a halt even in release, so the 
compiler won't optimize away the branch like it should.

Heh, I just realized, that particular special case is another 
argument for a separate function, because assert(false) can't 
express unreachability. assume(false) could.

> (Can we programmatically (sp?) identify and flag/resolve
> issues that occur from a mismatch of expectations?)

I'm not an expert on this, but my guess is it's possible in 
theory but would never happen in practice. Such things are very 
complex to implement, if Walter won't agree to a simple and easy 
solution, I'm pretty sure there's no way in hell he would agree 
to a complex one that takes a massive amount of effort.


More information about the Digitalmars-d mailing list