On Wednesday, 30 July 2014 at 16:25:41 UTC, John Colvin wrote:
> On Wednesday, 30 July 2014 at 15:49:33 UTC, Daniel Murphy wrote:
>> "Tofu Ninja"  wrote in message news:dtjqnyucskwnqjvksawg@forum.dlang.org...
>>
>>> Question?
>>> If an if condition throws or returns in its body is it ok for the optimizer to 'assume' that the condition is false after and make optimizations for it? If so then every one complaining that assert gets removed in -release should really just be using enforce.
>>
>> Yes.  In fact, it's required that an optimizer do this in order not to be considered garbage.
>>
>>> The possibility for the optimizer to make the same optimizations for assert can be done for enforce, the only difference is that it does not get removed in -release....
>>
>> Not quite.  With enforce, it is impossible (ignoring hardware or optimizer errors) for the condition to be false if the enforce was not triggered. Because the assert is not checked, the condition could be false and the code could do something awful.
>>
>> Also, the optimizer can only use the enforce's assumption _after_ it has checked the condition.  Since with assert it doesn't need to check, it can go backwards and assume the previous code will never produce a value that can violate the assertion.
>>
>> if (y > 7) // x can't possibly be >= 5, so this can't be true
>> x = y + 1;
>> assert(x < 5);
>>
>> if (y > 7) // the program will throw if >= 5, but that doesn't mean it can't be true
>> x = y + 1;
>> enforce(x < 5);
>>
>> Assert is much much more powerful.
>
> So what is the recommended way of inserting a check of the sort that Ola would like?
>
> debug enforce(expr);
>
> perhaps? Seeing as that statement is completely missing outside of debug mode, the compiler can't do anything much about it.
>
>
> P.S. What about version(assert)? Could the optimiser work with this:
>
> if(x > 7) x++;
> version(assert) auto testResult = x;
> assert(x <= 7);

ugh, I made a mess of that one. Should be

if(x > 7) x++;
version(assert) auto testResult = x;
assert(testResult <= 7);

"Timon Gehr"  wrote in message news:lrb5pd$1uv$1@digitalmars.com...

> On a more serious note, are you trying to argue that there are no pragmatic differences in software quality based on the obvious fact that the system running the software is implemented on top of uncertain physics?

No, I was saying that in any verified system there will be a portion that is just trust. 

On 07/30/2014 05:04 PM, Andrei Alexandrescu wrote:
> On 7/30/14, 4:56 AM, Daniel Murphy wrote:
>> "Artur Skawina via Digitalmars-d"  wrote in message
>> news:mailman.217.1406713015.16021.digitalmars-d@puremagic.com...
>>
>>> `assert` is for *verifying* assumptions. It must not allow them
>>> to leak/escape. Otherwise a single not-100%-correct assert could
>>> defeat critical runtime checks.
>>
>> All you're saying is you want them to have different names, not that it
>> can't work the way Walter and I have described.  If your assertions are
>> invalid and you're compiling with -release, the compiler is free to
>> generate invalid code.  -release is dangerous.  -release is telling the
>> compiler that the code you wrote is correct,  and it can rely on it to
>> be correct.
>
> Exactly! -- Andrei

This just moves the issue around and gives another term a non-obvious meaning (the 'release' switch, which is not called e.g. 'unsafeAssumeCorrect'. Which is still confusing, because it purports to keep memory safety intact in @safe code by not disabling array bounds checks by default). This is the very topic of this discussion: some people get confused when they are assumed to use standard terms with non-standard meanings. I was objecting to the apparent attitude that this is entirely the fault of the one who gets confused, or that it is symptomatic for lack of understanding of concepts.

I mean, we have at least:

some terms with whacky meanings for an outsider:
'release' which does not relate to a released code version and which is not in contrast to 'debug'.
'const' which does not relate to being a constant.
'enum' which does not denote enumeration in many contexts where it is used.
'in' which does not only check for membership but rather returns a pointer to that member.
'lazy', which denotes pass by name instead of pass by need.
'pure' which denies access to mutable static variables and IO.
... (some more easily debatable ones removed)


some terms with inconsistent meanings:
'alias': alias declarations and alias parameters are notably distinct: while I can alias a built-in type to a symbol, I cannot pass it by alias. The following fails:

template T(alias a){ enum T=2; }
pragma(msg, T!string);


(Before debate ensues: I am completely aware of what each of the above actually mean and do.)

To me, the apt response to a relative newcomer who gets confused by one of those or something like them, especially when used without quotation marks, is not at all similar to "You're misunderstanding and misusing this feature, stop making noise."

On 07/30/2014 06:30 PM, Daniel Murphy wrote:
> "Timon Gehr"  wrote in message news:lrb5pd$1uv$1@digitalmars.com...
>
>> On a more serious note, are you trying to argue that there are no
>> pragmatic differences in software quality based on the obvious fact
>> that the system running the software is implemented on top of
>> uncertain physics?
>
> No, I was saying that in any verified system there will be a portion
> that is just trust.

Obviously.

(That this was the point was not obvious to me because it already holds in purely formal systems, there is not actually a need to shave off abstractions.)

"Ary Borenszweig"  wrote in message news:lrb6ev$2ln$1@digitalmars.com...

> > Because if assert only means 'check this condition' then the optimizer
> > can't optimize based on the assumption that it's true.
>
> Assert means: check this condition and terminate the program if it doesn't hold.
>
> So why can't the compiler optimize based on this?

The compiler can optimize based on this.  But with that definition of assert it can't optimize based on the assumption that the condition is always true, without checking it first. 

"John Colvin"  wrote in message news:mmnpehpddzkduycydcnh@forum.dlang.org...

> So what is the recommended way of inserting a check of the sort that Ola would like?
>
> debug enforce(expr);
>
> perhaps? Seeing as that statement is completely missing outside of debug mode, the compiler can't do anything much about it.

Don't use -release.

> P.S. What about version(assert)? Could the optimiser work with this:
>
> if(x > 7) x++;
> version(assert) auto testResult = x;
> assert(x <= 7);

No, version(assert) is just about doing introspection on the compiler's configuration.  In release mode that code doesn't even get semantically analysed. 

On 07/30/2014 04:11 PM, Daniel Murphy wrote:
> "Artur Skawina via Digitalmars-d"  wrote in message
> news:mailman.227.1406728603.16021.digitalmars-d@puremagic.com...
>
>> "D - the language that redefines commonly used and universally
>> understood terms and concepts"?
>
> Yes, see pure for another example.  "D - the pragmatic language"
> ...

I don't think it is a posteriori justified by pragmatism, or that this is even a way to increase conceived or actual pragmatism.

>> > not that it can't work the way Walter and I have described.
>>
>> Possible != sane.
>>
>> The main problem isn't even the terminology; it's the consequences
>> wrt safety and correctness.
>
> Yes, this is a much more useful discussion to have than what other
> people have definined assert to do.

My impression has been:
This is the discussion Ola wanted to have in the first place. He defined all the terminology he was using, and the distinction was relevant, because it actually captured the 'consequences wrt safety and correctness'. Then his terminology was picked up as a convenient vector for 'attack' and his point was ignored.

"Timon Gehr"  wrote in message news:lrb6lf$2tf$1@digitalmars.com...

> I mean, we have at least:
> <list>

You forgot 'float', which has nothing to do with levitation.

This is all true, yet we have to pick names for things.  We could call D's purity 'flarwurghle', but is that really better?  D's purity is much more closely related to other concepts of purity than it is to flarwurghling.

And don't forget int, which is not actually an integer.

> To me, the apt response to a relative newcomer who gets confused by one of those or something like them, especially when used without quotation marks, is not at all similar to "You're misunderstanding and misusing this feature, stop making noise."

No, but that is the similar to the correct response when somebody repeatedly argues that you've defined something wrong because somebody else defined it differently.

The discussion on how we _should_ define it is much more interesting, and ideally the other one would not come up at all. 

On 07/30/2014 05:28 PM, H. S. Teoh via Digitalmars-d wrote:
> Yeah, I think this hair-splitting between assume and assert is ... pure
> hair-splitting.

Which is pure name-calling.

On 07/30/2014 06:43 PM, Daniel Murphy wrote:
> "John Colvin"  wrote in message
> news:mmnpehpddzkduycydcnh@forum.dlang.org...
>
>> So what is the recommended way of inserting a check of the sort that
>> Ola would like?
>>
>> debug enforce(expr);
>>
>> perhaps? Seeing as that statement is completely missing outside of
>> debug mode, the compiler can't do anything much about it.
>
> Don't use -release.
>
>> P.S. What about version(assert)? Could the optimiser work with this:
>>
>> if(x > 7) x++;
>> version(assert) auto testResult = x;
>> assert(x <= 7);
>
> No, version(assert) is just about doing introspection on the compiler's
> configuration.  In release mode that code doesn't even get semantically
> analysed.

Isn't this also true for assert statements?