On 8/3/2014 4:01 PM, Timon Gehr wrote:
> Walter is not a supernatural being.

Yes, I am. I demand tribute.

> 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?)

On 8/6/2014 8:18 AM, David Bregman wrote:

>>
>> 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. That's in the
> past. This is all about the pros and cons of changing it now and for the
> future.

You keep going on the premise that your definition is the intended definition. I completely disagree. My understanding of assert has always been as Walter has described it. To me, *that* is the existing definition and yours is completely new. Nothing is being changed. He's just talking about starting to take advantage of it as he has always intended to.

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

On Wednesday, 6 August 2014 at 00:47:28 UTC, Walter Bright wrote:
> If you build dmd in debug mode, and then run it with -O --c, it will give you a list of all the data flow transformations it does.
>
> But the list is a blizzard on non-trivial programs.

Awesome, thanks! Will give it a whirl, as soon as my vacation is over.

On Wednesday, 6 August 2014 at 01:39:25 UTC, Mike Parker wrote:
> On 8/6/2014 8:18 AM, David Bregman wrote:
>
>>>
>>> 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. That's in the
>> past. This is all about the pros and cons of changing it now and for the
>> future.
>
> You keep going on the premise that your definition is the intended definition. I completely disagree. My understanding of assert has always been as Walter has described it. To me, *that* is the existing definition and yours is completely new. Nothing is being changed. He's just talking about starting to take advantage of it as he has always intended to.

No, intention is orthogonal to this. Again, this is all about the pros and cons of changing the *actual* semantics of assert.

On Wednesday, 6 August 2014 at 01:39:25 UTC, Mike Parker wrote:
> On 8/6/2014 8:18 AM, David Bregman wrote:
>

>
> You keep going on the premise that your definition is the intended definition. I completely disagree. My understanding of assert has always been as Walter has described it.

I did not use to think the same, but once Walter stated his vision of assert(), it was like a kind of revelation to me: why the optimizer won't make use of such obvious information like assert() provides just like asimple:

if(x<5) {
      // you can safely optimize this code knowing (*assuming*) that always x<5
}

But, what started to bother me lately and, I think, is the root of the problem: to have programmer code disabled by a compiler flag. I do not speak about boundschecking, where the code is never explicitely written by the programmer, but of real programmer code.

Until now, versioning (or, in C/C++, the #ifdef) was the sole acceptable way to disable programmer code. The C assert slipped through as being based on a #ifdef or #if (I know good compilers will also optimize a if(0), but this is just because it happens to be obvious).

OTOH, the D assert is no longer based (directly) on versioning, so having it disabled by a flag is not easily grasped. This, combined with the sudden revelation of the optimizer messing with it, produced a shock and this thread illustrates it. People are just to used to its secondary meaning from C, that is, besides testing conditions: "easily obtain a log of what and where was wrong". So, it was an assertion, but also a logging feature (albeit a fatal one). People got used with assert() becoming noop code in the release mode, just like they would disable the logs for release.

The more I think about it, the more I feel like assert would be more naturally an annotation or a kind of versioning. Still, I cannot come with a clear cut proposition, as my mind is also entangled in old habits. One one hand, it feels natural as an instruction, on the other hand, being disable-able, maybe even ignorable (in release builds) and an invalidating point for the program logic*, it should belong somewhere else.

*I think this is important: is not only a tested condition that is then handled, but a tested condition exposing a "does not work as intended". It looks more like a kind of "this code should be unreachable".

On Wednesday, 6 August 2014 at 02:43:17 UTC, eles wrote:
> On Wednesday, 6 August 2014 at 01:39:25 UTC, Mike Parker wrote:
>> On 8/6/2014 8:18 AM, David Bregman wrote:

> *I think this is important: is not only a tested condition that is then handled, but a tested condition exposing a "does not work as intended". It looks more like a kind of "this code should be unreachable".

nitpicking: is not "my program does not behave like expected (for example, because the config file is broken)" but "my code wasn't supposed to say that and I did not mean to write such code"

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.

On Wednesday, 6 August 2014 at 00:52:32 UTC, Walter Bright wrote:
> On 8/3/2014 4:51 PM, Mike Farnsworth wrote:
>> This all seems to have a very simple solution, to use something like: expect()
>
> I see code coming that looks like:
>
>    expect(x > 2);  // must be true
>    assert(x > 2);  // check that it is true
>
> All I can think of is, shoot me now :-)

How about something like
@expected assert(x > 2); or @assumed assert(x > 2);

It wouldn't introduce a new keyword, but still introduces the
expected/assumed semantics. You should keep in mind that you
might have to make a compromise, regardless of your feelings on
the subject.


Also, I am going to try to say this in as respectful a way as I
can...

Please stop responding in such a dismissive way, I think it is
already pretty obvious that some are getting frustrated by these
threads. Responding in a dismissive way makes it seem like you
don't take the arguments seriously.

On Wednesday, 6 August 2014 at 04:05:41 UTC, David Bregman wrote:
> On Wednesday, 6 August 2014 at 01:11:55 UTC, Jeremy Powers via Digitalmars-d wrote:

> 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

I feel that, at this stage, is only about how a compiler glag, specifically "-release" works. For other configurations, there is no problem: event if the optimizer optimizes based on asserts, the asserts themselves are part of the code: code is there and the assertion will fail before execution enters the optimized path. This is just like any other optimization, nothing special about it.

The problem with "-release" might be formulated in that it optimizes based on a code that is no longer present (the asserts are wiped out). It keeps the optimization, but it dismisses the garde-fous.