On 07/30/2014 07:59 PM, Daniel Murphy wrote:
> "Timon Gehr"  wrote in message news:lrbb2a$6du$1@digitalmars.com...
>
>> The second issue is that the statement above tries to look like it is
>> tautological by seeming to express both factual information and an
>> opinion at the same time.
>
> I prefer to assume statements have no deceptive intent.

Me too and I am sure none was present. What I want to say is that the effect of the statement is deceptive.

On Wednesday, 30 July 2014 at 16:43:47 UTC, 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.

haha yeah, or that!

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

pity.

"Ary Borenszweig"  wrote in message news:lrbbp8$6t2$1@digitalmars.com... 

> So... it's exactly the same as assert?

Yes!  Wait, no.  Sorta.

http://forum.dlang.org/post/lrb608$26m$1@digitalmars.com

On 7/30/14, 2:56 PM, Andrei Alexandrescu wrote:
> On 7/30/14, 9:31 AM, Timon Gehr wrote:
>> 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'.
>
> Well to me "-release" is "I assume my program is correct, generate the
> fastest code for it".

I tried the program in debug mode in thousands of ways and apparently no assert triggers. So I'll just compile in release mode, release it and let anyone find bugs in it and allow to bypass any security or safety I put in my program with those "assert" statmenets, that would probably just take 1 nanosecond to execute anyway.

Sounds really nice.

(sorry for the sarcasm, removing assert is wrong to me)

On 07/30/2014 08:06 PM, John Colvin wrote:
>
>
>>> 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.
>
> pity.

assert({ ... }());

On 7/30/14, 11:13 AM, Ary Borenszweig wrote:
> On 7/30/14, 2:56 PM, Andrei Alexandrescu wrote:
>> On 7/30/14, 9:31 AM, Timon Gehr wrote:
>>> 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'.
>>
>> Well to me "-release" is "I assume my program is correct, generate the
>> fastest code for it".
>
> I tried the program in debug mode in thousands of ways and apparently no
> assert triggers. So I'll just compile in release mode, release it and
> let anyone find bugs in it and allow to bypass any security or safety I
> put in my program with those "assert" statmenets, that would probably
> just take 1 nanosecond to execute anyway.
>
> Sounds really nice.
>
> (sorry for the sarcasm, removing assert is wrong to me)

Sometimes it's wrong sometimes it's required. I think there is an understanding that sometimes every extra bit of speed is necessary. We wouldn't imagine deploying hhvm with assertions enabled.

Andrei

On Wednesday, 30 July 2014 at 14:46:20 UTC, Daniel Murphy wrote:
> "Wyatt"  wrote in message news:wpyvrdoofziktwqkzqbf@forum.dlang.org...
>
>> I think the point here is that usually, when the optimiser changes the semantics of valid code, it's considered a bug in the optimiser.
>
> s/usually/always/
>
> The thing is, code containing an assertion that is not always true is not valid code.

Seeing this response, my Ordinary Programmer Brain says, "Well yeah, of course it's not valid once you remove the assertion; you've fundamentally changed the meaning of the whole thing!  If it were fine to remove the assertion, I wouldn't have used it in the first place."

Something (possibly the thing where "For fastest executables, compile with the -O -release -inline -boundscheck=off" is standard advice to anyone asking about performance) tells me this point needs to be made MUCH more clear wherever possible or the ghost of Scott Meyers will haunt us all.  But that it's even a problem tells me we're facing a pattern of human error.  Is there no good way to eliminate it?

It seems pretty clear that there's a class of runtime check that is for debugging only that can be eliminated because you believe the code will never be used for evil; and there's a class of check where, no matter what, if some condition isn't met the application should immediately halt and catch fire lest it do something horrible.  Additionally raised in this thread is a class of expression that's only evaluated at compile time for the sake of making optimisations where you're saying "It's all right, I made sure this is good, go to town".

The distinction between the former two things in D apparently comes down to whether you put your assert() as its own expression or as the ThenStatement of an IfStatement, while the latter has been conflated into the first.  That there's prior art regarding the terminology and semantics only confuses the issue further.  Incidentally, this conversation actually forced me to look into the semantics of assert() in C and C++, and it turns out it's moderately muddy, but it seems they're only eliminated if you #define NDEBUG?

-Wyatt

"Ary Borenszweig"  wrote in message news:lrbbtl$778$1@digitalmars.com...

> If assume stays in release mode then that's the difference. The problem then is that assert doesn't stay in release mode so the compiler can't make any assumption about the code that follows the "assert" because asserts are removed in release mode.

assume never creates a runtime check, assert does in non-release mode. assert's condition can't be 'assumed' in non-release mode, or the compiler could simply assume the check passed an non emit it.

> In my opinion, removing asserts in release-mode is the big problem here. How expensive can an assert be? Do you really want to debug that? Wouldn't it be better to get an exception?

That's the whole point of assert+release.  If you always want an exception, simply use enforce.

> If the compiler *never* removes asserts, then assert and assume have the same meaning.

No, because assert puts in a runtime check in non-release.

Hopefully my table helps.  I'm not sure which assert I'm talking about half the time. 

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

> > Don't use -release.
>
> haha yeah, or that!

debug enforce(...) would also work just fine.  It depends if you're happy with leaving bounds checking enabled, if you want fine-grained control over which checks get enabled, if your code needs to be nothrow, etc

I often write quick scripts that rely on bounds checking and assertions to reject incorrect command line args.  While this is technically an abuse of assert, it doesn't matter because I never use -release on them. 

On Wed, Jul 30, 2014 at 03:13:06PM -0300, Ary Borenszweig via Digitalmars-d wrote:
> On 7/30/14, 2:56 PM, Andrei Alexandrescu wrote:
[...]
> >Well to me "-release" is "I assume my program is correct, generate the fastest code for it".
> 
> I tried the program in debug mode in thousands of ways and apparently no assert triggers. So I'll just compile in release mode, release it and let anyone find bugs in it and allow to bypass any security or safety I put in my program with those "assert" statmenets, that would probably just take 1 nanosecond to execute anyway.
> 
> Sounds really nice.
> 
> (sorry for the sarcasm, removing assert is wrong to me)

If you want the check to always be there, use enforce, not assert.


T

-- 
Без труда не выловишь и рыбку из пруда.