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