www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Only want to say

reply ddcovery <antoniocabreraperez gmail.com> writes:
This last year I started a new project and (as people that reads 
this forum knows) I decided not to use D as primary language:  I 
really was not enough experienced and I required a fast way to 
launch my prototypes (some difficulties like debugging or 
inspecting variables or strange linux erros with hunt/vibe.d 
frameworks stopped me)...

I decided not to use either Go or Rust:

* Go is pure imperative/structured language and a hell in terms 
of modular structuring of your project.  It is not suitable for a 
"functional" orientation... and my pure imperative way of 
thinking was abandoned decades ago:  I want to write map/reduce 
expressions instead for/if loops when possible.

* Rust is a straitjacket with the ownership management:  may be 
it is great way of avoiding erros, but codding flexibility is 
very limited

I wanted to return to a strong typed/native compiled language, 
but Go/Rust were not comparable in terms of productivity (and 
expressiveness) with Scala+Play or Java+Spring Boot or 
Node+typescript...

Finally, I decided to use D as a day-by-day scripting/common 
tasks language (for acquire experience) and I only want to say 
one thing:

D rocks

* The modularity of my scripting tasks is simple: I can organize 
my code in folders/modules an run scripts directly: no paths, no 
projects... only code and run.
* The in/out/body (and scope) mechanism/syntax is awesome (I 
really love it)
* The function first parameter possibilities calling ways removes 
the need of "extension" methods and it is something I really 
appreciate.
* The standard library is really useful.
* The way memory is managed transparently is awesome:  I'm not 
afraid of pointers and manually managed memory ... but being able 
to forget about it in your project is a dream.
* The functional syntax is really flexible (I will love a more 
integrated functional way of working in all std library, but I 
understand that it is out of D scope... D is not a functional 
language but a language with good support for functional 
programming).
* Templates instead Generics power/flexibility is awesome (each 
time I write format!"..."(...) I feel a positive emotion 
difficult to describe).

May be, I will appreciate to work with "asynchronicity" naturally 
as part of the language itself,  but it is not mandatory for me 
and I will cover my needs using vibe.d in the next months.  May 
be I will appreciate not opening brackets on new line (I have 
some vision difficulties... and this "standard" forces me to 
scroll a lot in the code because I use a big font size)

In summary:  D is a productive great language and I'm sure I will 
increase it's use next months.

I just wanted to share a bit of the positive feelings that D has 
given me over the last few months and wish the team that 
continues to work day by day despite the difficulties my sincere 
thanks and best wishes.
Jan 04 2021
next sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 1/4/21 4:51 AM, ddcovery wrote:


 * The in/out/body (and scope) mechanism/syntax is awesome (I really love
 it)


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")
{
   // ...
}


 May be I will appreciate not opening brackets on new line


I agree with you. I use "Egyption brackets" throughout my own code 
except when it helps with separation like in the code above. Otherwise, 
in/out and template constraints look too close to the body of the function.

Ali
Jan 04 2021
next sibling parent reply ddcovery <antoniocabreraperez gmail.com> writes:
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 :-))
Jan 11 2021
next sibling parent reply ddcovery <antoniocabreraperez gmail.com> writes:
On Monday, 11 January 2021 at 10:14:36 UTC, ddcovery wrote:

 ...
 * 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.
 ...


Oh my God, I found 
https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1003.md

It seems that "body" will be deprecated in favor of "do"... I 
find this decision specially bad but I suppose I will eat it with 
potatoes (spanish expression).

Imagine someone saying "Because we want to use 'catch' for 
catching errors with promises in JavaScript, we decide to 
deprecate 'catch' in the try/catch structure).   Internet 
Explorer was this incompatibility and everybody was to write 
["catch"] for bypassing the IE problem... actually "catch" is 
used in promises and as language itself and there is no problems.

what "do" signifies?  "if precondition, then do... and check 
postcondition" it is a "sequential" way to express something 
that, in my opinion, must be declarative:  "this method has a 
precondition, a postcondition and a body"

As I say... I will adapt to the new term... but it is clearly how 
"imperative" developers doesn't accept "declarative" way of 
thinking... sometimes

In special this kind of affirmation:

"Furthermore, D's contract programming features are rarely used 
compared to how useful and desirable it is to be able to name a 
symbol "body"

Oh my God... one of the most powerful tools of D are belittled.

Seriously?... this is the kind of decisions that makes me doubt 
about D future.
Jan 11 2021
next sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Monday, 11 January 2021 at 13:43:38 UTC, ddcovery wrote:

 Seriously?... this is the kind of decisions that makes me doubt 
 about D future.


On the contrary :)
in/out/body is barely more useful than simply... assert()
hence it ended up not being used in a meaningful capacity, apart 
from curiosity
Jan 11 2021
parent ddcovery <antoniocabreraperez gmail.com> writes:
On Monday, 11 January 2021 at 13:48:06 UTC, Guillaume Piolat 
wrote:

 On Monday, 11 January 2021 at 13:43:38 UTC, ddcovery wrote:

 Seriously?... this is the kind of decisions that makes me 
 doubt about D future.


 On the contrary :)
 in/out/body is barely more useful than simply... assert()
 hence it ended up not being used in a meaningful capacity, 
 apart from curiosity


post-condition is hard to implement with asserts... basically you 
must "wrap" your function to check the result... I find 
out(result){ ... } or out(result; condition; message) an example 
of how programming theory can be applied to the real world... 
this proves (like with invariant implementation) that people 
under D (Walter in this case) appreciates this way of thinking to 
the point that they incorporate it into language.

And I really appreciate this.
Jan 11 2021
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 1/11/21 8:43 AM, ddcovery wrote:

 On Monday, 11 January 2021 at 10:14:36 UTC, ddcovery wrote:

 ...
 * 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.
 ...


 Oh my God, I found 
 https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1003.md
 
 It seems that "body" will be deprecated in favor of "do"... I find this 
 decision specially bad but I suppose I will eat it with potatoes 
 (spanish expression).
 
 Imagine someone saying "Because we want to use 'catch' for catching 
 errors with promises in JavaScript, we decide to deprecate 'catch' in 
 the try/catch structure).   Internet Explorer was this incompatibility 
 and everybody was to write ["catch"] for bypassing the IE problem... 
 actually "catch" is used in promises and as language itself and there is 
 no problems.
 
 what "do" signifies?  "if precondition, then do... and check 
 postcondition" it is a "sequential" way to express something that, in my 
 opinion, must be declarative:  "this method has a precondition, a 
 postcondition and a body"
 
 As I say... I will adapt to the new term... but it is clearly how 
 "imperative" developers doesn't accept "declarative" way of thinking... 
 sometimes
 
 In special this kind of affirmation:
 
 "Furthermore, D's contract programming features are rarely used compared 
 to how useful and desirable it is to be able to name a symbol "body"
 
 Oh my God... one of the most powerful tools of D are belittled.
 
 Seriously?... this is the kind of decisions that makes me doubt about D 
 future.


I highly doubt we will remove body in that syntax. The DIP proposed 
that, but that was under the expectation that we couldn't remove body as 
a keyword without also removing its support in that position.

Today, body is *not* a keyword, but can be used there. I don't think it 
will ever change. See the PR that was reverted because it affected a lot 
of code: https://github.com/dlang/dmd/pull/10763

And I have to say, this is quite the overreaction. "body" vs. "do" is 
not the thing that makes contracts function, let alone should cause you 
to doubt the future of D.

But this is kind of a side-thing, I'm glad you are loving the language, 
I share that emotion completely!

-Steve
Jan 11 2021
parent reply ddcovery <antoniocabreraperez gmail.com> writes:
On Monday, 11 January 2021 at 14:06:01 UTC, Steven Schveighoffer 
wrote:

 ...

 I highly doubt we will remove body in that syntax. The DIP 
 proposed that, but that was under the expectation that we 
 couldn't remove body as a keyword without also removing its 
 support in that position.

 Today, body is *not* a keyword, but can be used there. I don't 
 think it will ever change. See the PR that was reverted because 
 it affected a lot of code: 
 https://github.com/dlang/dmd/pull/10763

 And I have to say, this is quite the overreaction. "body" vs. 
 "do" is not the thing that makes contracts function, let alone 
 should cause you to doubt the future of D.

 But this is kind of a side-thing, I'm glad you are loving the 
 language, I share that emotion completely!

 -Steve


100,000 apologies, Steve. You're right: it was an overreaction.

The cause is not about do vs body (well, partly yes)... it is 
about an accepted DIP telling that Contract programming is not 
enough important in D community and can be belittled... I have to 
recognize that it was a shock for me (because it is,with scope, 
the basis of all scripting I'm working with D, and one of the 
most used arguments in some posts in quora or when I present D to 
other developers).

Thank you very much for clarifying the situation so quickly.
Jan 11 2021
parent reply Meta <jared771 gmail.com> writes:
On Monday, 11 January 2021 at 14:38:58 UTC, ddcovery wrote:

 On Monday, 11 January 2021 at 14:06:01 UTC, Steven 
 Schveighoffer wrote:

 ...

 I highly doubt we will remove body in that syntax. The DIP 
 proposed that, but that was under the expectation that we 
 couldn't remove body as a keyword without also removing its 
 support in that position.

 Today, body is *not* a keyword, but can be used there. I don't 
 think it will ever change. See the PR that was reverted 
 because it affected a lot of code: 
 https://github.com/dlang/dmd/pull/10763

 And I have to say, this is quite the overreaction. "body" vs. 
 "do" is not the thing that makes contracts function, let alone 
 should cause you to doubt the future of D.

 But this is kind of a side-thing, I'm glad you are loving the 
 language, I share that emotion completely!

 -Steve


 100,000 apologies, Steve. You're right: it was an overreaction.

 The cause is not about do vs body (well, partly yes)... it is 
 about an accepted DIP telling that Contract programming is not 
 enough important in D community and can be belittled... I have 
 to recognize that it was a shock for me (because it is,with 
 scope, the basis of all scripting I'm working with D, and one 
 of the most used arguments in some posts in quora or when I 
 present D to other developers).

 Thank you very much for clarifying the situation so quickly.


I am the author of that DIP, and you are grossly mis-interpreting 
what I'm saying there. I am not saying that contract programming 
is not important; on the contrary, I think it is very important 
and use D's contract programming features whenever possible. 
However, I seem to be in the minority in that regard in the D 
community, and people have been complaining for 10+ years about 
not being able to use `body` as the name for a symbol. In that 
context, it does not make sense to tie up a very commonly used 
symbol name for a relatively underused feature.

As for `do`, that was not my idea; I originally proposed using 
`function` instead of body, but Andrei opted for `do` instead.

Regardless, it doesn't matter much now, as was mentioned, because 
body is now only a keyword in the context of function contracts.
Jan 11 2021
parent reply ddcovery <antoniocabreraperez gmail.com> writes:
On Monday, 11 January 2021 at 16:21:55 UTC, Meta wrote:


 ...
 I am the author of that DIP, and you are grossly 
 mis-interpreting what I'm saying there. I am not saying that 
 contract programming is not important; on the contrary, I think 
 it is very important and use D's contract programming features 
 whenever possible.


My apologies for the mis-interpreting.


 However, I seem to be in the minority in that regard in the D 
 community, and people have been complaining for 10+ years about 
 not being able to use `body` as the name for a symbol.


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 ).


 In that context, it does not make sense to tie up a very 
 commonly used symbol name for a relatively underused feature.

 As for `do`, that was not my idea; I originally proposed using 
 `function` instead of body, but Andrei opted for `do` instead.

 Regardless, it doesn't matter much now, as was mentioned, 
 because body is now only a keyword in the context of function 
 contracts.


Thank you very much Meta for the clarifications and the effort 
that as a community you have dedicated to me.
Jan 11 2021
parent reply Jacob Carlborg <doob me.com> writes:
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.

There are several problems with the implementation of contracts 
in D, which I think make them less useful and contribute to the 
reason why they're not very commonly used.

* in-contracts are not included in the generated documentation
* in-contracts are executed by the callee instead of the caller
* No compile time check of contracts are performed, if it would 
be possible
* DMD ships with a standard library compiled for release builds, 
i.e. without contracts and asserts. LDC on the other hand, ships 
both a with debug build and with a release build of the standard 
library

--
/Jacob Carlborg
Jan 12 2021
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
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.
Jan 12 2021
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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.
Jan 12 2021
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
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?
Jan 12 2021
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
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.
Jan 12 2021
prev sibling parent reply ddcovery <antoniocabreraperez gmail.com> writes:
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.
Jan 12 2021
parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
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/
Jan 13 2021
parent ddcovery <antoniocabreraperez gmail.com> writes:
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!!!
Jan 13 2021
prev sibling parent ddcovery <antoniocabreraperez gmail.com> writes:
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!!!
Jan 12 2021
prev sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 11 January 2021 at 13:43:38 UTC, ddcovery wrote:

 It seems that "body" will be deprecated in favor of "do"


Both work equally well, have for a long time now, and I expect 
will continue to.

It used to be you couldn't name a variable `body` or whatever 
because of the keyword status. That's fixed. It doesn't affect 
other things.

Don't get too worked up about DIPs.
Jan 11 2021
prev sibling parent reply kdevel <kdevel vogtner.de> writes:
On Monday, 11 January 2021 at 10:14:36 UTC, ddcovery wrote:

[...]


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

   ...
 }


Just my 2 ¢: This is not DbC as I understand it. The conditions
do not reflect a program state one "can reason about". Furthermore
there is at least one race condition [1] which would be absent if
the file system operations just fail and throw an exception.

[1] https://en.wikipedia.org/wiki/Time-of-check_to_time-of-use
Jan 11 2021
parent reply ddcovery <antoniocabreraperez gmail.com> writes:
On Monday, 11 January 2021 at 19:33:26 UTC, kdevel wrote:

 On Monday, 11 January 2021 at 10:14:36 UTC, ddcovery wrote:

 [...]


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

   ...
 }


 Just my 2 ¢: This is not DbC as I understand it. The conditions
 do not reflect a program state one "can reason about".


It's true.  I suppose you mainly refer to assertions over shared 
(not exclusive) resources: you can't "snapshot" a pre/post state 
and demonstrate that your function is the responsible of this 
transformation.

But the think here is I'm running a set of batch commands (not 
only 7z) over folders/files assuming that no other one is 
interested in.

It is a really relaxed scenery, but enough for the tasks.



 Furthermore
 there is at least one race condition [1] which would be absent 
 if
 the file system operations just fail and throw an exception.

 [1] https://en.wikipedia.org/wiki/Time-of-check_to_time-of-use


Absolutelly.  the pre-assert and post-assert are only 
"informative" (documentation) and a development help (I wrote 
assertions before code).  The zip (really a .7z) is performed 
using 7z command execution an response code is checked to raise 
the exception:  important I/O checking is performed as "athomic" 
as possible:

This is the complete method code:

...
void generateZip(string srcPath, string zipPath )
in
{
   assert(srcPath.exists());
}
out
{
   assert(zipPath.exists());
}
body
{
   import std.file : chdir, getcwd;
   import std.path: absolutePath;

   scope (failure)
     "Problems generating 7z file".writeln();

   auto dstPath = zipPath.absolutePath();
   auto actualDir = getcwd();
   scope (exit)
     chdir(actualDir);

   chdir(srcPath);
   format!"7z a %s"(dstPath).exec();
}
...
void exec(string cmd)
{
   import std.process : wait, spawnShell;

   auto result = cmd.spawnShell().wait(); //wait(spawnShell(cmd));
   if (result != 0)
     throw new object.Error(format!"Problems executing command. 
Exit code %d"(result));
}
Jan 11 2021
parent reply Jacob Carlborg <doob me.com> writes:
On Monday, 11 January 2021 at 22:12:15 UTC, ddcovery wrote:


 It's true.  I suppose you mainly refer to assertions over 
 shared (not exclusive) resources: you can't "snapshot" a 
 pre/post state and demonstrate that your function is the 
 responsible of this transformation.

 But the think here is I'm running a set of batch commands (not 
 only 7z) over folders/files assuming that no other one is 
 interested in.

 It is a really relaxed scenery, but enough for the tasks.


`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.

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.

`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.

--
/Jacob Carlborg
Jan 12 2021
parent reply ddcovery <antoniocabreraperez gmail.com> writes:
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
Jan 12 2021
parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
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
Jan 12 2021
prev sibling parent reply ddcovery <antoniocabreraperez gmail.com> writes:
On Monday, 4 January 2021 at 18:21:59 UTC, Ali Çehreli wrote:

 On 1/4/21 4:51 AM, ddcovery wrote:


 * The in/out/body (and scope) mechanism/syntax is awesome (I


 really love

 it)


 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")
 {
   // ...
 }


 May be I will appreciate not opening brackets on new line


 I agree with you. I use "Egyption brackets" throughout my own 
 code except when it helps with separation like in the code 
 above. Otherwise, in/out and template constraints look too 
 close to the body of the function.

 Ali


thanks again for the tip.

A question (May be this is something to the learn forum):

Is it possible to us in/out in a lambda expression?
Jan 11 2021
parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 1/11/21 2:52 AM, ddcovery wrote:


 Is it possible to us in/out in a lambda expression?


I don't think so. I guess, if it has contracts, it deserves to be a 
proper function. :)

Ali
Jan 11 2021
parent Meta <jared771 gmail.com> writes:
On Monday, 11 January 2021 at 16:53:42 UTC, Ali Çehreli wrote:

 On 1/11/21 2:52 AM, ddcovery wrote:


 Is it possible to us in/out in a lambda expression?


 I don't think so. I guess, if it has contracts, it deserves to 
 be a proper function. :)

 Ali


It seems that it does work, but you need to include the 
`function()` preamble; it doesn't seem to like including 
contracts with the short-form function literals.

void test(void function() f)
{
     f();
}

void main()
{
     test(function() in(1 == 0) out(; 1 == 0) {}); //Okay
}
Jan 11 2021
prev sibling next sibling parent reply aberba <karabutaworld gmail.com> writes:
On Monday, 4 January 2021 at 12:51:57 UTC, ddcovery wrote:

 [...]


Funny enough, I just submitted an article on scripting in D :)



 [...]
Jan 04 2021
parent reply ddcovery <antoniocabreraperez gmail.com> writes:
On Monday, 4 January 2021 at 22:09:30 UTC, aberba wrote:

 On Monday, 4 January 2021 at 12:51:57 UTC, ddcovery wrote:

 [...]


 Funny enough, I just submitted an article on scripting in D :)



 [...]




Hi Lawrence.  Where can I find the article?
Jan 04 2021
parent aberba <karabutaworld gmail.com> writes:
On Tuesday, 5 January 2021 at 00:50:34 UTC, ddcovery wrote:

 On Monday, 4 January 2021 at 22:09:30 UTC, aberba wrote:

 On Monday, 4 January 2021 at 12:51:57 UTC, ddcovery wrote:

 [...]


 Funny enough, I just submitted an article on scripting in D :)



 [...]




 Hi Lawrence.  Where can I find the article?


It'll be published on OpenSource.com in about 2 weeks :(. Their 
publishing queue takes a while.

However, I'm going to write a different kind of scripting post 
for my blog sooner.
Jan 04 2021
prev sibling parent reply Tobias Pankrath <tobias+dlang pankrath.net> writes:
On Monday, 4 January 2021 at 12:51:57 UTC, ddcovery wrote:

 In summary:  D is a productive great language and I'm sure I 
 will increase it's use next months.


That D is productive and fun to write while being suitable for 
low-level and high-perf applications to scripting tasks, is its 
main selling point to me as well.

But I think we're falling behind by trying to copy the success of 
languages instead of concentrating on our core strength.

Tuples, named arguments, string interpolation >  live
Jan 05 2021
next sibling parent reply aberba <karabutaworld gmail.com> writes:
On Tuesday, 5 January 2021 at 11:46:06 UTC, Tobias Pankrath wrote:

 On Monday, 4 January 2021 at 12:51:57 UTC, ddcovery wrote:

 In summary:  D is a productive great language and I'm sure I 
 will increase it's use next months.


 That D is productive and fun to write while being suitable for 
 low-level and high-perf applications to scripting tasks, is its 
 main selling point to me as well.

 But I think we're falling behind by trying to copy the success 
 of languages instead of concentrating on our core strength.

 Tuples, named arguments, string interpolation >  live


Yes for me also, unless you're lowe-level a system. Apparently 
they see things differently.

D for scripting and productivity is hugely unexploited.
Jan 05 2021
parent reply welkam <wwwelkam gmail.com> writes:
On Tuesday, 5 January 2021 at 12:58:58 UTC, aberba wrote:

 D for scripting and productivity is hugely unexploited.


I have the same feeling
Jan 05 2021
parent M.M. <matus email.cz> writes:
On Tuesday, 5 January 2021 at 15:31:34 UTC, welkam wrote:

 On Tuesday, 5 January 2021 at 12:58:58 UTC, aberba wrote:

 D for scripting and productivity is hugely unexploited.


 I have the same feeling


Aberba's blog will be a good start to showcase D in that light. I 
remember that there was also the suggestion to turn the 
"one-line-usage of dmd from within shell" into a blog (in a 
response to how H. S. Teoh and probably others use dmd for 
one-line shell-scripting). Could be a nice mini-series.
Jan 05 2021
prev sibling parent reply Andre Pany <andre s-e-a-p.de> writes:
On Tuesday, 5 January 2021 at 11:46:06 UTC, Tobias Pankrath wrote:

 On Monday, 4 January 2021 at 12:51:57 UTC, ddcovery wrote:

 In summary:  D is a productive great language and I'm sure I 
 will increase it's use next months.


 That D is productive and fun to write while being suitable for 
 low-level and high-perf applications to scripting tasks, is its 
 main selling point to me as well.

 But I think we're falling behind by trying to copy the success 
 of languages instead of concentrating on our core strength.

 Tuples, named arguments, string interpolation >  live


Yes, tuples are a core strength of D, but the syntax is not 
great. My hope is with the tuple dip we will be able to have a 
python like syntax:

(Python numpy example)
arr = numpy.array([('a', 0), ('b', 1)])

My gut feeling is, we will be able to compete with numpy if we 
can provide tuple syntax as python can provide.

Also named arguments is really important here, fortunately there 
is already someone working on the implementation of the approved 
dip.

Kind regards
Andre
Jan 05 2021
next sibling parent M.M. <matus email.cz> writes:
On Tuesday, 5 January 2021 at 13:05:30 UTC, Andre Pany wrote:

 On Tuesday, 5 January 2021 at 11:46:06 UTC, Tobias Pankrath 
 wrote:

 [...]


 Yes, tuples are a core strength of D, but the syntax is not 
 great. My hope is with the tuple dip we will be able to have a 
 python like syntax:

 (Python numpy example)
 arr = numpy.array([('a', 0), ('b', 1)])

 My gut feeling is, we will be able to compete with numpy if we 
 can provide tuple syntax as python can provide.

 Also named arguments is really important here, fortunately 
 there is already someone working on the implementation of the 
 approved dip.

 Kind regards
 Andre


We should get Timon on sabbatical...
Jan 05 2021
prev sibling next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Tuesday, 5 January 2021 at 13:05:30 UTC, Andre Pany wrote:

 On Tuesday, 5 January 2021 at 11:46:06 UTC, Tobias Pankrath 
 wrote:

 [...]


 Yes, tuples are a core strength of D, but the syntax is not 
 great. My hope is with the tuple dip we will be able to have a 
 python like syntax:

 (Python numpy example)
 arr = numpy.array([('a', 0), ('b', 1)])

 My gut feeling is, we will be able to compete with numpy if we 
 can provide tuple syntax as python can provide.

 Also named arguments is really important here, fortunately 
 there is already someone working on the implementation of the 
 approved dip.

 Kind regards
 Andre


+1 here. I think "modern" data science should be done with D! 
Think of performance 🍀
Jan 06 2021
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2021-01-05 14:05, Andre Pany wrote:


 Yes, tuples are a core strength of D, but the syntax is not great. My 
 hope is with the tuple dip we will be able to have a python like syntax:
 
 (Python numpy example)
 arr = numpy.array([('a', 0), ('b', 1)])
 
 My gut feeling is, we will be able to compete with numpy if we can 
 provide tuple syntax as python can provide.


I would love to have a better syntax for tuples in D but I'm very 
skeptical that D would be anymore or less suitable to do the same things 
as numpy does only based on getting a better tuple syntax.

The above example could be implemented as a variadic template in D:

auto arr = array('a', 0, 'b', 1); // less syntax then the Python example

Template constraints can be used to make sure there are even number of 
arguments and of the correct types.

-- 
/Jacob Carlborg
Jan 06 2021
parent Andre Pany <andre s-e-a-p.de> writes:
On Wednesday, 6 January 2021 at 17:56:59 UTC, Jacob Carlborg 
wrote:

 On 2021-01-05 14:05, Andre Pany wrote:


 Yes, tuples are a core strength of D, but the syntax is not 
 great. My hope is with the tuple dip we will be able to have a 
 python like syntax:
 
 (Python numpy example)
 arr = numpy.array([('a', 0), ('b', 1)])
 
 My gut feeling is, we will be able to compete with numpy if we 
 can provide tuple syntax as python can provide.


 I would love to have a better syntax for tuples in D but I'm 
 very skeptical that D would be anymore or less suitable to do 
 the same things as numpy does only based on getting a better 
 tuple syntax.

 The above example could be implemented as a variadic template 
 in D:

 auto arr = array('a', 0, 'b', 1); // less syntax then the 
 Python example

 Template constraints can be used to make sure there are even 
 number of arguments and of the correct types.


Maybe yes, but I am not 100 % sure, as in your example the 
information about the dimension count is lost.

In the numpy example you can see there are 2 columns with 2 rows. 
Your example is an 1 dimension array.

Here I am not sure how the n-dimendions info can be specified in 
a readable way using variadic templates.

King regards
Andre
Jan 06 2021