November 10, 2014
Meta:

> On the other hand, making assert a built-in that provides optimization hints has been proposed for C++17:

Thank you for the link.


> http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4154.pdf

But that behavour is on request (using NDEBUG = strong), it's not suddenly becoming the default for D as Walter suggested:

<<
To satisfy as many users as possible, four levels of assertion are provided:	
• Default: assert evaluates its condition and generates a diagnostic upon failure.	
• NDEBUG = strong: assert has no side effects, but the implementation may use the
condition, and if it would fail, the behavior is undefined. This provides optimal hints.	
• NDEBUG = strict: The assert expression is fully parsed and semantically checked,
but no evaluation occurs. The behavior is still defined even if it would evaluate as false, but
this may be considered unlikely.	
• NDEBUG defined as empty or an integer literal: The assert operands are syntactically a
balanced-token-seq. Otherwise this is the same as strict mode.	
• Other identifiers in the expansion of NDEBUG are reserved to the standard for future
expansion, except for identifiers usually reserved to the library.
>>

If you write a program from the start using NDEBUG=strong you are relying on a different semantics for assert. It's essentially a different kind of assert. You can't take D programs and silently change the basic semantics of all asserts under them. And still, in many cases you don't want to use NDEBUG=strong, that's why there are also other available behaviours like NDEBUG=strict that is an intermediate point.

I think this proposal n4154 is a bit over-engineered (as it often happens to C++), but it avoids most of the faults in Walter ideas: it avoids breaking existing code (because the default behavour doesn't change), allows optimizations on request, etc.

In practice I prefer to avoid using hacks like setting a NDEBUG. It's better to have differently named operators if their behavour is different. So it's better to keep the assert() as it is commonly used (and I'd like it to refuse a not pure expression). And add another operator, like strong_assert() for the NDEBUG=strong behavour. (And if you can't live with it, you can also add a strict_assert()). Changing the behavour of asserts just changing a global constant is silly because what matters is the semantics the programmer gives to the assert he/she/shi is using. So giving them different names is much better.

Walter is right in his very strong engineer desire to keep designs as simple as possible; but often giving the same name to things with different semantics doesn't reduce the complexity, it just increases the confusion. I greatly prefer when things with different semantics have cleanly distinct names.

Bye,
bearophile
November 10, 2014
On Sunday, 9 November 2014 at 22:41:29 UTC, H. S. Teoh via Digitalmars-d-learn wrote:
> On Sun, Nov 09, 2014 at 09:57:21PM +0000, eles via Digitalmars-d-learn wrote:
>> On Sunday, 9 November 2014 at 16:31:46 UTC, bearophile wrote:
>> >H. S. Teoh:
>> >
>> >>It's only a bad idea because people abuse assert() where it's not
>> >>appropriate.
>> >
>> >It's a bad idea because Walter seems unable to understand the
>> >difference between verifying and proving.
>> 
>> I fail to see the difference between assert() and a hypothetical
>> assume().
>
> The original meaning of assert() is what assume() means nowadays,
> whereas nowadays what people think of as assert() is actually what
> enforce() does in Phobos.

No, enforce() is obviously intended for verifying user input, not for checking program logic, that's why it throws an Exception, not an Error. The documentation even says so explicitly:

http://dlang.org/phobos/std_exception.html#.enforce
November 10, 2014
On 11/09/2014 11:39 PM, H. S. Teoh via Digitalmars-d-learn wrote:
>
> The original meaning of assert() is what assume() means nowadays,
> whereas nowadays what people think of as assert() is actually what
> enforce() does in Phobos.
>
>
> T
>

No.
November 10, 2014
On 11/09/2014 05:24 PM, H. S. Teoh via Digitalmars-d-learn wrote:
> On Sun, Nov 09, 2014 at 04:12:06PM +0000, bearophile via Digitalmars-d-learn wrote:
>> H. S. Teoh:
>>
>>> Walter *did* mention recently that he was planning to eventually take
>>> advantage of information in assert()'s as optimizer hints. Not sure
>>> when this will happen, though, but it seems inevitable at some point.
>>
>> And it caused a storm, because it's an awfully bad idea.
> [...]
>
> It's only a bad idea because people abuse assert() where it's not
> appropriate.
>
>
> T
>

Some do, but that's basically orthogonal to why this is a bad idea.
November 11, 2014
On Monday, 10 November 2014 at 10:27:19 UTC, bearophile wrote:
> In practice I prefer to avoid using hacks like setting a NDEBUG. It's better to have differently named operators if their behavour is different. So it's better to keep the assert() as it is commonly used (and I'd like it to refuse a not pure expression). And add another operator, like strong_assert() for the NDEBUG=strong behavour. (And if you can't live with it, you can also add a strict_assert()). Changing the behavour of asserts just changing a global constant is silly because what matters is the semantics the programmer gives to the assert he/she/shi is using. So giving them different names is much better.

In my experience asserts don't show such distinction, and it's impractical to decide such things in advance. So I think, a compiler switch makes more sense.
1 2
Next ›   Last »