<div dir="ltr"><div class="gmail_extra"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
That's in the past. This is all about the pros and cons of changing it now and for the future.<br></blockquote></div><br></div><div class="gmail_extra">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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">The below can safely be ignored, as I just continue the pedantic discussions....<br></div><div class="gmail_extra">
<br></div><div class="gmail_extra"><br></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
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.<div class=""><br></div></blockquote><div><br></div><div>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.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
The 'regular' definition of assert that you claim is what I see as<br>
the redefinition - it is a definition based on the particular<br>
implementation of assert in other languages, not on the conceptual idea of<br>
assert as I understand it (and as it appears to be intended in D).<br>
</blockquote>
<br></div>
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.<div class="">
<br></div></blockquote><div><br></div><div>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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

This appears to be the root of the argument, and has been circled<br>
repeatedly... it's not my intent to restart another round of discussion on<br>
that well traveled ground, I just wanted to state my support for the<br>
definition as I understand it.<br>
</blockquote>
<br></div>
I disagree. I don't think the fact that some people already had the new definition in mind before is really all that relevant. </blockquote><div><br></div><div>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...</div>
<div><br></div><div>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.</div>
<div><br></div><div><div class="gmail_extra">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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">In an attempt to return this discussion to something useful, question:<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">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?)</div>
<div class="gmail_extra"><br></div></div><div class="gmail_extra"><br></div></div></div></div>