On Tuesday, 12 January 2021 at 14:02:02 UTC, Jacob Carlborg wrote:
> * in-contracts are not included in the generated documentation

I actually tried to solve this in adrdox. It is simple enough to print them, but the Phobos contracts tend to be hideous and completely unhelpful for understanding the function. So I disabled the feature.

Some libs, especially those written with the simpler new syntax, are much nicer though, so I might try enabling that again.

On Tuesday, 12 January 2021 at 13:52:48 UTC, Jacob Carlborg wrote:

> ...
> `assert` should be used to verify logical assumptions in your program. To verify things in the environment, exceptions should be used. You can drop the `in` and `out` contracts and use the `enforce` function the same way as `assert` is used. It will throw an exception if the condition doesn't hold.

Yes, totally agree

>
> Exceptions inheriting from the class `Exception` should be thrown when there's an error related to the environment. I.e. a missing file, failed to connect to a server and so on.
>
> Exceptions inheriting from the class `Error` should be thrown when there's a logical error in the program, this is what `assert` does. This includes accessing an array outside of its bounds, failing to handle all cases in a `final switch` statement and so on.

I didn't know about this distinction in D... thank you for the help!!! (I am throwing "error" instead "exception": I will be careful with this distinction)

>
> `assert` and contracts can be removed from the code, depending on which compiler flags are being used. Exceptions will always stay.
>
> In your case, there can be something like anti-virus software which is running in the background and decides to remove your files which the program is processing.

As I mentioned in the same post, I really use exceptions to manage IO operations (checking "previously" causes a race condition between check and operation:  it is the operation itself the one that must raise the exception)... my in/out assertions (as I mentioned in the same post) are really used for documentation purposes (I write assertions first and, then, the body code).

It is OK to remove at release time the contracts, because code is totally "contract" independent

Note:  I found that "invariant" for classes/structs can be removed using a compiler flag, but I didn't found information about removing the in/out... is it performed directly by compiler when generating a release?
>
> --
> /Jacob Carlborg

Thanks a lot Jacob

On Tuesday, 12 January 2021 at 14:02:02 UTC, Jacob Carlborg wrote:
> On Monday, 11 January 2021 at 18:33:58 UTC, ddcovery wrote:
>
>> I understand... As long as I have seen, the own std library makes an intensive use of unitesting and avoids the in/out contract keywords (mainly, I suppose, because it is a "run-time" check with the obvious performance fault ).
>
> No, it's not a performance issue, contracts can be disabled at compile time and are in the standard library.
>
Yes I see now (https://dlang.org/spec/contracts.html):  "It is important to ensure that the code has no side effects, and that the release version of the code will not depend on any effects of the code. For a release build of the code, in and out contracts are not inserted."

I really didn't see this paragraph (I was looking for a flag for "removing" in/out assertions at compile time).  My fault!!!

> --
> /Jacob Carlborg

Thankyou!!!

On Tue, Jan 12, 2021 at 02:33:23PM +0000, Adam D. Ruppe via Digitalmars-d wrote:
> On Tuesday, 12 January 2021 at 14:02:02 UTC, Jacob Carlborg wrote:
> > * in-contracts are not included in the generated documentation
> 
> I actually tried to solve this in adrdox. It is simple enough to print them, but the Phobos contracts tend to be hideous and completely unhelpful for understanding the function. So I disabled the feature.
> 
> Some libs, especially those written with the simpler new syntax, are much nicer though, so I might try enabling that again.

IMNSHO, if contracts are hideous and unhelpful, then they're not being used properly.  Contracts are supposed to document (and enforce) what the caller must fulfill when calling the function; they should be in a form that's readable and understandable to the user.  Any other conditions that don't fall in that category belong as asserts in the function body, not in the contract.


T

-- 
Don't modify spaghetti code unless you can eat the consequences.

On Tuesday, 12 January 2021 at 17:04:14 UTC, H. S. Teoh wrote:
> IMNSHO, if contracts are hideous and unhelpful, then they're not being used properly.  Contracts are supposed to document (and enforce) what the caller must fulfill when calling the function;

Maybe it is possible to write a specification language as a template library and compile it down with mixins to the "ugly" internal representation?

On 1/12/21 6:41 AM, ddcovery wrote:

> I didn't know about this distinction in D... thank you for the help!!!
> (I am throwing "error" instead "exception": I will be careful with this
> distinction)

In case someone finds more wording on the matter useful:

  http://ddili.org/ders/d.en/exceptions.html#ix_exceptions.Exception

  http://ddili.org/ders/d.en/assert.html


http://ddili.org/ders/d.en/contracts.html#ix_contracts.assert%20vs.%20enforce

> Note:  I found that "invariant" for classes/structs can be removed using
> a compiler flag, but I didn't found information about removing the
> in/out... is it performed directly by compiler when generating a release?

-release command line switch should remove all contracts (except perhaps for @safe code? I'm not sure.)

Ali

On 12.01.21 18:04, H. S. Teoh wrote:
>  > they should be in a
> form that's readable and understandable to the user.
> Any other conditions that don't fall in that category belong as asserts in the
> function body, not in the contract.

If an assert fails in the function body, the function has a bug. If an assert fails in the in contract, the caller has a bug. I understand that some people don't take this very seriously for pragmatic reasons, but one should at least be aware that this is supposed to be the convention.

Modular correctness is great, runtime checking maybe not so much.

On Tuesday, 12 January 2021 at 14:33:23 UTC, Adam D. Ruppe wrote:
> On Tuesday, 12 January 2021 at 14:02:02 UTC, Jacob Carlborg wrote:
>> * in-contracts are not included in the generated documentation
>
> I actually tried to solve this in adrdox. It is simple enough to print them, but the Phobos contracts tend to be hideous and completely unhelpful for understanding the function. So I disabled the feature.
>
> Some libs, especially those written with the simpler new syntax, are much nicer though, so I might try enabling that again.

After reading this comment, I decided to abandon the in{} out{} body/do{} syntax (sorry for the discussion I initiated about de "do" vs "body" :-( ):

* The simpler new version seems to fit with the D standard functions syntax well (without the need of "alien" body/do words):  it introduces new blocks without changing the syntax of the existing ones.

* The simpler contract syntax enforces using declarative assertions and removes (partially) the possibility of imperative code in contracts. (good for documentation)

The only small problem I found is you can not import exclusive contract dependencies (because you have not a block)... but this is not a real problem.

On 1/12/21 2:46 PM, ddcovery wrote:

> The only small problem I found is you can not import exclusive contract
> dependencies (because you have not a block)... but this is not a real
> problem.

A reminder of the self-important[1] D idiom.

auto foo(string s)
in (from!"std.uni".isUpper(from!"std.range".front(s))) {
  return s;
}

void main() {
  foo("Hello");
}

template from(string moduleName)
{
  mixin("import from = " ~ moduleName ~ ";");
}

Ali

[1] https://dlang.org/blog/2017/02/13/a-new-import-idiom/

On Wednesday, 13 January 2021 at 16:58:31 UTC, Ali Çehreli wrote:
> On 1/12/21 2:46 PM, ddcovery wrote:
>
> > The only small problem I found is you can not import
> exclusive contract
> > dependencies (because you have not a block)... but this is
> not a real
> > problem.
>
> A reminder of the self-important[1] D idiom.
>
> auto foo(string s)
> in (from!"std.uni".isUpper(from!"std.range".front(s))) {
>   return s;
> }
>
> void main() {
>   foo("Hello");
> }
>
> template from(string moduleName)
> {
>   mixin("import from = " ~ moduleName ~ ";");
> }
>
> Ali
>
> [1] https://dlang.org/blog/2017/02/13/a-new-import-idiom/

OMG... thank you Ali!!!