Only want to say

[ddcovery]

On Monday, 4 January 2021 at 18:21:59 UTC, Ali Çehreli wrote:
> On 1/4/21 4:51 AM, ddcovery wrote:
> ...
> I totally agree. Just to make sure you are aware that 'body' is 
> optional for a while:
>
> int foo(int i)
> in (i > 42, format!"invalid: %s"(i))
> out (result; result > 100, "oops")
> {
>   // ...
> }
>
Yes, it is really compact: thanks for the tip Ali.

I have a "personal" conflict between the compact and extended 
version:
* The use of brackets ensures an equivalent indentation between 
precondition, post-condition and body (it is like writing an 
if/else):  I find it more readable.
* The compact version, after getting used to its syntax, allows a 
more compact code, but VSCode "code-d" is really intrusive when 
formatting and does "strange" things when in/out statements are 
too small:  it moves them to the same line!!!.
* Finally, with the "extended" version,  I use "body" instead 
"do":  in/out/body are not verbs... "do" is a verb.  it's a 
subtle difference, but it's very important to me.

Basically it is:

void zipTo(string srcPath, string zipPath)
in (srcPath.exists()) out(;zipPath.exists())  //<- VSCode moves 
"out" to the same line!!!
{
   scope (failure)
     "Problems generating 7z file".writeln();

   ...
}

vs

void zipTo(string srcFolder, string zipFile)
in
{
   assert(srcFolder.exists());
}
out
{
   assert(zipPath.exists());
}
body
{
   scope (failure)
     "Problems generating 7z file".writeln();

   ...
}


The good thing is that D offers enough syntax flexibility 
allowing you to use the one that best suits your 
needs/preferences.

This is a great feature that other "modern" languages are 
ignoring.
* May be it is because they prefer to use "unit" testing instead 
a "rich" contract mechanism (because the two ones conflict when 
used simultaneously):  contracts are the best "auto-document" 
mechanism although it may introduce some inefficiencies in the 
code when used "exhaustively" as a substitute for unit-testing 
(they are "run-time" contract checking, not "compile-time").  I 
find it is a good practice to use the two ones and decide witch 
checks are really "preconditions"/"postconditions" and witch 
checks are tests.

* Other question is how other languages could use 
precondition/postcondition with some new paradigms like 
"generators" or "corutines" where a function acts as an stream 
asynchronous consumer/producer:  D generators are really Ranges 
and precondition/postcondition/invariant fits nicely (I'll think 
about it when I really need it, I'm not experienced enought :-))