assert semantic change proposal

Jeremy Powers via Digitalmars-d digitalmars-d at puremagic.com
Tue Aug 5 18:11:44 PDT 2014


> 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.



The below can safely be ignored, as I just continue the pedantic
discussions....


OK, but my point was you were using a different definition of undefined
> behavior. We can't communicate if we aren't using the same meanings of
> words.
>
>
Yes, very true.  My definition of undefined in this case hinges on my
definition of what assert means.  If a failed assert means all code after
it is invalid, then by definition (as I interpret the definition) that code
is invalid and can be said to have undefined behaviour.  That is, it makes
sense to me that it is specified as undefined, by the spec that is
incredibly unclear.  I may be reading too much into it here, but this
follows the strict definition of undefined - it is undefined because it is
defined to be undefined.  This is the 'because I said so' defense.



>  The 'regular' definition of assert that you claim is what I see as
>> the redefinition - it is a definition based on the particular
>> implementation of assert in other languages, not on the conceptual idea of
>> assert as I understand it (and as it appears to be intended in D).
>>
>
> The 'regular' definition of assert is used in C, C++ and for the last
> >10years (afaik), in D. If you want to change it you need a good
> justification. I'm not saying such justification necessarily exist doesn't
> either, maybe it does but I have not seen it.
>
>
This 'regular' definition is a somewhat strict interpretation of the
definition to only match how languages have implemented it.  I have always
interpreted the intent of assert to be 'here is something that must be
true, if it is not then my program is in an invalid state' - the fact it is
only a debug halting tool in practice means it falls short of its
potential.  And in fact I very rarely use it in practice for this reason,
as I find the way it works almost useless and definitely dangerous.



> This appears to be the root of the argument, and has been circled
>> repeatedly... it's not my intent to restart another round of discussion on
>> that well traveled ground, I just wanted to state my support for the
>> definition as I understand it.
>>
>
> I disagree. I don't think the fact that some people already had the new
> definition in mind before is really all that relevant.


It comes back to whether the new definition is actually new.  If it is a
new definition, then we can argue about whether it is good or not.  If it
is the old definition (which slightly differs from how assert works in
practice in other languages) then we can argue about whether D should
conform to other languages or leverage the existing definition...

I contend that it is not new, and is simply an extension of the actual
definition.  Some people agree, some people don't... very lengthy and
esoteric discussions have already spiraled through this repeatedly, so us
arguing about it again probably won't get anywhere.

My stance is that this new/old definition is a good thing, as it matches
how I thought things were already, and any code that surfaces as broken
because of it was already broken in my definition.  Therefore this 'change'
is good, does not introduce breaking changes, and arguments about such
should be redirected towards mitigation and fixing of expectations.

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?  (Can we programmatically (sp?) identify and flag/resolve
issues that occur from a mismatch of expectations?)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140805/2e3e976b/attachment.html>


More information about the Digitalmars-d mailing list