6 ms·

Just a personal anecdote, Walter Bright's Digital Mars C++ compiler also had the contracts (D started life almost literally as recycled code from Mr. Bright's o

Just a personal anecdote, Walter Bright's Digital Mars C++ compiler also had the contracts (D started life almost literally as recycled code from Mr. Bright's other compilers - he wrote a native Java compiler, a Javascript 1.3 stdlib, and a C++ compiler with a bunch of extensions.... smash those together and you have the early D releases!). Anyway, I used the DM C++ compiler originally because it was the only one I could download to the high school computers without filling out a form, and pimply-face youth me saw "DESIGN BY CONTRACT" at the top of the website and got kinda excited thinking it was a way to make some easy money coding online. Imagine my disappointment when I saw it was just in/out/invariant/assert features. (I'm pretty sure D had just come out when I saw that, but I saw `import` instead of `#include` and dismissed it as a weenie language. Came back a couple years later and cursed my younger self for being a fool! lol)

WalterBright 1y ago
The in/out features come into their own when inheritance is in play, i.e. for member functions of classes and interfaces. See https://dlang.org/spec/function.html#in_out_inheritance https://dlang.org/spec/function.html#in_out_inheritance `import` is so cool we extended it to be able to import .c files! The D compiler internally translates them to D so they can be used. When this was initially proposed, the reaction was "what's that good for?" It turned out to be incredibly useful and a huge time saver. The concept is sort of like C++ being a superset of C and so being able to incorporate C code, except unlike C++, the C syntax can be left behind. After all, don't we get tired of: struct Tag { ... } Tag; ?
- 1718627440 1y ago
  > struct Tag { ... } Tag; What's the thing with the syntax? If you don't intend to use the type elsewhere don't give it a tag, if you want, you have to give it a name. (Assuming you are annoyed by the duplicate Tag)
  - WalterBright 1y ago
    Which would you prefer: struct Tag { ... } or: typedef struct Tag { ... } Tag; ? It's just simpler and easier to write code in D than in C/C++. For another example, in C/C++: int foo(); int bar() { return foo(); } int foo() { return 3; } The D equivalent: int bar() { return foo(); } int foo() { return 3; }
    - 1718627440 1y ago
      If the user of Tag is supposed to know how the internal details: struct Tag { ... }; if it needs to rely on the internals, but the user shouldn't care: typedef struct { ... } Tag; if it can be opaque (what I would default to): typedef struct {} Tag; I also think that is a good feature to separate specification from implementation, I like being forced to declare first what I want to implement. Funnily in your special case you wouldn't need the declaration. (But of course it's a bad idea to rely on this "feature")
WalterBright 1y ago
My C++ compiler also implemented contracts back in the 90s: https://www.digitalmars.com/ctg/contract.html https://www.digitalmars.com/ctg/contract.html Modern C++ is slowly adopting D features, many of which came from extensions I added to my C++ compiler.

WalterBright 1y ago

The in/out features come into their own when inheritance is in play, i.e. for member functions of classes and interfaces. See https://dlang.org/spec/function.html#in_out_inheritance https://dlang.org/spec/function.html#in_out_inheritance `import` is so cool we extended it to be able to import .c files! The D compiler internally translates them to D so they can be used. When this was initially proposed, the reaction was "what's that good for?" It turned out to be incredibly useful and a huge time saver. The concept is sort of like C++ being a superset of C and so being able to incorporate C code, except unlike C++, the C syntax can be left behind. After all, don't we get tired of: struct Tag { ... } Tag; ?

1718627440 1y ago
> struct Tag { ... } Tag; What's the thing with the syntax? If you don't intend to use the type elsewhere don't give it a tag, if you want, you have to give it a name. (Assuming you are annoyed by the duplicate Tag)
- WalterBright 1y ago
  Which would you prefer: struct Tag { ... } or: typedef struct Tag { ... } Tag; ? It's just simpler and easier to write code in D than in C/C++. For another example, in C/C++: int foo(); int bar() { return foo(); } int foo() { return 3; } The D equivalent: int bar() { return foo(); } int foo() { return 3; }
  - 1718627440 1y ago
    If the user of Tag is supposed to know how the internal details: struct Tag { ... }; if it needs to rely on the internals, but the user shouldn't care: typedef struct { ... } Tag; if it can be opaque (what I would default to): typedef struct {} Tag; I also think that is a good feature to separate specification from implementation, I like being forced to declare first what I want to implement. Funnily in your special case you wouldn't need the declaration. (But of course it's a bad idea to rely on this "feature")

WalterBright 1y ago

My C++ compiler also implemented contracts back in the 90s: https://www.digitalmars.com/ctg/contract.html https://www.digitalmars.com/ctg/contract.html Modern C++ is slowly adopting D features, many of which came from extensions I added to my C++ compiler.