On Saturday, 27 January 2018 at 18:00:32 UTC, rjframe wrote:
> I think I see what you mean; you interpret "use asserts, because enforce will be compiled out" to imply that asserts wouldn't be compiled out, correct?

Is there any other meaningful interpretation?

> Since, in reality, both would be compiled out, it shouldn't matter what you use, so the docs shouldn't care. That makes sense.

That's precisely my point.

> The documentation seems to assume the reader has certain expectations of assert and enforce[0], so each function expresses a different intention to the programmer; when I see `assert()` I expect those checks only in non- release mode; when I see `enforce()` I expect those checks regardless of the flags that have been set[1]. Placing `enforce` in a contract messes with that expectation.

Right.

> What language here would make more sense to you? Anything I can come up with is either awkward or pretty verbose.

I suggest the deletion of the sentence "Use assert in contracts."

On 01/27/2018 10:33 AM, kdevel wrote:

> I suggest the deletion of the sentence "Use assert in contracts."

Done.

Ali

On Saturday, 27 January 2018 at 22:53:37 UTC, Ali Çehreli wrote:
> On 01/27/2018 10:33 AM, kdevel wrote:
>
>> I suggest the deletion of the sentence "Use assert in contracts."
>
> Done.
>
> Ali

Wait, no this isn't right, is it? Enforce should not be used in contracts so the "Use assert in contracts" statement is correct and should remain. I think the issue here is the OP is getting confused between assert vs. exception.

Contracts (in D) are used to define and assert the agreed logic behaviour of the program code.

Asserts catch logic bugs in the code that may lead to incorrect behaviour at runtime. Exceptions are for exceptional cases that crop up at runtime due to factors external to the code logic, e.g. invalid external state such as failing to open a file or a sensor not going off when it should because it is faulty.

Asserts can be removed in -release code because it is assumed the logic has been asserted correct during debug builds and testing. The same reason compilers now are starting to optimise out code based on assert conditions.

bye,
lobo

On 01/27/2018 04:59 PM, lobo wrote:
> On Saturday, 27 January 2018 at 22:53:37 UTC, Ali Çehreli wrote:
>> On 01/27/2018 10:33 AM, kdevel wrote:
>>
>>> I suggest the deletion of the sentence "Use assert in contracts."
>>
>> Done.
>>
>> Ali
>
> Wait, no this isn't right, is it?

It is right because that statement made one person to replace 'enforce's with 'asserts's.

> Enforce should not be used in
> contracts so the "Use assert in contracts" statement is correct and
> should remain.

I don't think enforce documentation is the right place to get into such matters. Warning against a potential misuse is fine but hinting at "correct use of assert vs. enforce" is not only distracting but also misguiding.

> I think the issue here is the OP is getting confused
> between assert vs. exception.
>
> Contracts (in D) are used to define and assert the agreed logic
> behaviour of the program code.
>
> Asserts catch logic bugs in the code that may lead to incorrect
> behaviour at runtime. Exceptions are for exceptional cases that crop up
> at runtime due to factors external to the code logic, e.g. invalid
> external state such as failing to open a file or a sensor not going off
> when it should because it is faulty.
>
> Asserts can be removed in -release code because it is assumed the logic
> has been asserted correct during debug builds and testing. The same
> reason compilers now are starting to optimise out code based on assert
> conditions.
>
> bye,
> lobo

All true.

Ali

On Sun, 28 Jan 2018 00:59:12 +0000, lobo wrote:

> On Saturday, 27 January 2018 at 22:53:37 UTC, Ali Çehreli wrote:
>> On 01/27/2018 10:33 AM, kdevel wrote:
>>
>>> I suggest the deletion of the sentence "Use assert in contracts."
>>
>> Done.
>>
>> Ali
> 
> Wait, no this isn't right, is it? Enforce should not be used in contracts so the "Use assert in contracts" statement is correct and should remain. I think the issue here is the OP is getting confused between assert vs. exception.

Without that statement, the documentation is still pretty clear that you shouldn't use enforce in contracts, so removing it won't hurt anything, and does make things clearer by staying on-topic.

On 1/27/18 9:31 AM, Ali Çehreli wrote:
> On 01/27/2018 05:52 AM, kdevel wrote:
>  > https://dlang.org/phobos/std_exception.html#enforce states:
>  >
>  > | Also, do not use enforce inside of contracts (i.e. inside of in and
>  > out blocks
>  > | and invariants), because they will be compiled out when compiling with
>  > -release.
>  > | Use assert in contracts.
>  >
>  > But assert is also ignored in release mode:
> 
> The documentation is not clear. "they will be compiled out" means "contracts are compiled out". So, an enforce() would disappear if it's inside such a block, which should not be what the programmer wants for an enforce().

There is another problem with using enforce in contracts, it throws Exceptions, whereas contracts are expected to throw Errors. The most important aspect about this is that nothrow functions can still throw Errors. So if you have a nothrow function with an in-contract that throws an Exception, compiling in release mode may is a mistake (I'm not sure if the compiler even detects this).

I think the current docs (as they have been modified) are fine.

> Fixed it through the "Improve this page" link on that Phobos page:
> 
>    https://github.com/dlang/phobos/blob/master/std/exception.d
> 
> Ali

Hm... it appears that you committed directly to the branch. Even if changing docs, you should do so with a pull request.

For normal mortals, this happens automatically, but for people who have commit rights, you have to be careful to select the right thing ;)

-Steve

On 01/28/2018 11:31 AM, Steven Schveighoffer wrote:

>> Fixed it through the "Improve this page" link on that Phobos page:
>>
>>    https://github.com/dlang/phobos/blob/master/std/exception.d
>>
>> Ali
>
> Hm... it appears that you committed directly to the branch. Even if
> changing docs, you should do so with a pull request.
>
> For normal mortals, this happens automatically, but for people who have
> commit rights, you have to be careful to select the right thing ;)
>
> -Steve

Guilty as charged! Seb has already brought me to my senses by email.

Ali