On 07/29/2014 10:52 PM, Walter Bright wrote:
On 7/29/2014 1:07 PM, Timon Gehr wrote:
On 07/29/2014 03:07 AM, Walter Bright wrote:
On 7/28/2014 1:49 PM, "Ola Fosheim Grøstad"
<ola.fosheim.grostad+dl...@gmail.com>" wrote:
You might want to assert() that you have enough headroom in a
statically
allocated buffer when testing. Say you assert that the buffer is never
more than
50% full for normal loads. You obviously don't want the -release build
to make
such an assumption!

You're misunderstanding

He still has a point. This is just another case of the keyword not
matching the
semantics very well. It would be more aptly named 'assume' instead of
'assert'
(and be un-@safe if release mode is to trust it unconditionally.)

I find this splitting of hares between assume and assert to be entirely
meaningless.
...

They are dual concepts. Assert demands a property to hold, assume provides a property that holds.

_According to the previous posts in this discussion_, in release mode, 'assert' provides a property that holds without any demands.

All I was saying is that

1. This particular behaviour is characteristic for an assumption, not an assertion, according to the above characterisation, which is standard in certain communities, like people who are into verification of procedural programs.

2. Code containing such a construct must in general be monitored to ensure memory safety, hence can at most be @trusted.


and misusing assert.

'assume' is completely redundant with 'assert'.
Only if you assume _a priori_ the program to be correct.
...

To have different debug builds, use debug statements.
'version(assert) assert' is a better match here, because if one uses
'debug
assert', there is the possibility of passing both -debug and -release
and get
the undesired behaviour.

That cure sounds worse than the (supposed) problem.
...

I was just pointing out how to properly prevent optimization based on disabled assertions.

(Unless, of course, you want to tell me a compiler may assume that anything in a version(assert) block can be assumed to actually be part of the program by the optimizer, which is very hard to implement, and may not even make sense in all circumstances.

BTW what about the following gem?

version(assert){}
else int x=2;
assert({
    static if(is(typeof(x))) enum e=loopForever();
    return someExpression;
}());

Should I expect it to stall compilation starting from a certain optimization level in -release mode, or what should be going on here?)


I still have problems convincing people that assert is not to be used to
validate user input. Howinell is there any hope of getting anyone to
understand all this fine-grained hare-splitting? Heck, I don't see any
useful difference between assert and assume.

I hope this post cleared it up a little.

Reply via email to