www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Another idiom I wish were gone from phobos/druntime

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
I'm seeing another idiom that seems to become fashionable. Consider this 
excerpt from 
https://github.com/D-Programming-Language/phobos/blob/master/std/algorithm/iteration.d#L407:

             auto opSlice(size_t low, size_t high)
             in
             {
                 assert(low <= high);
             }
             body
             {
                 import std.range : take;
                 return this[low .. $].take(high - low);
             }

which of course trivially boils down to:

             auto opSlice(size_t low, size_t high)
             {
                 assert(low <= high);
                 import std.range : take;
                 return this[low .. $].take(high - low);
             }

What advantage could possibly be in transforming a 5-liner into a 
9-liner? Are we really aiming at writing the maximum possible lines of 
code here and using as many language features as possible everywhere?

I think we should dust off that Phobos contributors' guide. Sadly, there 
is little we can do against the more subtle issues.


Andrei
Feb 04 2015
next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 5/02/2015 1:24 p.m., Andrei Alexandrescu wrote:
 I'm seeing another idiom that seems to become fashionable. Consider this
 excerpt from
 https://github.com/D-Programming-Language/phobos/blob/master/std/algorithm/iteration.d#L407:


              auto opSlice(size_t low, size_t high)
              in
              {
                  assert(low <= high);
              }
              body
              {
                  import std.range : take;
                  return this[low .. $].take(high - low);
              }

 which of course trivially boils down to:

              auto opSlice(size_t low, size_t high)
              {
                  assert(low <= high);
                  import std.range : take;
                  return this[low .. $].take(high - low);
              }

 What advantage could possibly be in transforming a 5-liner into a
 9-liner? Are we really aiming at writing the maximum possible lines of
 code here and using as many language features as possible everywhere?

 I think we should dust off that Phobos contributors' guide. Sadly, there
 is little we can do against the more subtle issues.


 Andrei
So are we recommending against contract based programming for simple getter type methods? Personally I think those auto's are more important to get rid of in this code. They actually do harm for anyone reading the docs.
Feb 04 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/4/15 4:30 PM, Rikki Cattermole wrote:
 So are we recommending against contract based programming for simple
 getter type methods?
The shorter version is as contract based as the other.
 Personally I think those auto's are more important to get rid of in this
 code. They actually do harm for anyone reading the docs.
That would be a separate discussion. Andrei
Feb 04 2015
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

             auto opSlice(size_t low, size_t high)
             in
             {
                 assert(low <= high);
             }
             body
             {
                 import std.range : take;
                 return this[low .. $].take(high - low);
             }

 which of course trivially boils down to:

             auto opSlice(size_t low, size_t high)
             {
                 assert(low <= high);
                 import std.range : take;
                 return this[low .. $].take(high - low);
             }

 What advantage could possibly be in transforming a 5-liner into 
 a 9-liner?
Contracts can be read by tools, and they are part of the function signature. Contracts should be encouraged and increased, not discouraged. Bye, bearophile
Feb 04 2015
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 5 February 2015 at 00:35:50 UTC, bearophile wrote:
 Contracts can be read by tools, and they are part of the 
 function signature. Contracts should be encouraged and 
 increased, not discouraged.
I agree. Moreover, if the assert fails in the contract, in theory, we can point the error at the user's code. An assert inside the function is the function's responsibility. An assert in an in contract is the caller's responsibility. They're semantically different (even if dmd treats them the same way)
Feb 04 2015
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/4/15 4:37 PM, Adam D. Ruppe wrote:
 On Thursday, 5 February 2015 at 00:35:50 UTC, bearophile wrote:
 Contracts can be read by tools, and they are part of the function
 signature. Contracts should be encouraged and increased, not discouraged.
I agree. Moreover, if the assert fails in the contract, in theory, we can point the error at the user's code. An assert inside the function is the function's responsibility. An assert in an in contract is the caller's responsibility. They're semantically different (even if dmd treats them the same way)
Yah I concede this is a good point. Yet we're looking at an actual liability and are supposed to look at some vague possible future benefit. -- Andrei
Feb 04 2015
next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 5 February 2015 at 00:43:04 UTC, Andrei Alexandrescu 
wrote:
 Yah I concede this is a good point. Yet we're looking at an 
 actual liability and are supposed to look at some vague 
 possible future benefit. -- Andrei
There only a benefit because the coding style for contract is ridiculous. Let's fix the right problem here.
Feb 04 2015
prev sibling next sibling parent reply "Zach the Mystic" <reachzach gggmail.com> writes:
On Thursday, 5 February 2015 at 00:43:04 UTC, Andrei Alexandrescu 
wrote:
 On 2/4/15 4:37 PM, Adam D. Ruppe wrote:
 On Thursday, 5 February 2015 at 00:35:50 UTC, bearophile wrote:
 Contracts can be read by tools, and they are part of the 
 function
 signature. Contracts should be encouraged and increased, not 
 discouraged.
I agree. Moreover, if the assert fails in the contract, in theory, we can point the error at the user's code. An assert inside the function is the function's responsibility. An assert in an in contract is the caller's responsibility. They're semantically different (even if dmd treats them the same way)
Yah I concede this is a good point. Yet we're looking at an actual liability and are supposed to look at some vague possible future benefit. -- Andrei
I have an idea. Treat all assert statements which come before the first non-assert statement as part of the 'in' contract. I'm not saying the compiler has to generate a whole 'in' function, but these asserts can be internally tagged to behave *as if* in an 'in' contract. That solves the tooling problem and the too-much-code problem, no?
Feb 04 2015
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Zach the Mystic:

 I have an idea. Treat all assert statements which come before 
 the first non-assert statement as part of the 'in' contract. 
 I'm not saying the compiler has to generate a whole 'in' 
 function, but these asserts can be internally tagged to behave 
 *as if* in an 'in' contract. That solves the tooling problem 
 and the too-much-code problem, no?
Bad idea. We had DbC, let's start using it. Bye, bearophile
Feb 04 2015
parent "Zach the Mystic" <reachzach gggmail.com> writes:
On Thursday, 5 February 2015 at 05:48:43 UTC, bearophile wrote:
 Zach the Mystic:

 I have an idea. Treat all assert statements which come before 
 the first non-assert statement as part of the 'in' contract. 
 I'm not saying the compiler has to generate a whole 'in' 
 function, but these asserts can be internally tagged to behave 
 *as if* in an 'in' contract. That solves the tooling problem 
 and the too-much-code problem, no?
Bad idea. We had DbC, let's start using it. Bye, bearophile
My proposal is just effectively syntax sugar for DbC, which the average programmer (not you!) will actually want to use.
Feb 05 2015
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 5 February 2015 at 04:36:39 UTC, Zach the Mystic 
wrote:
 I have an idea. Treat all assert statements which come before 
 the first non-assert statement as part of the 'in' contract. 
 I'm not saying the compiler has to generate a whole 'in' 
 function, but these asserts can be internally tagged to behave 
 *as if* in an 'in' contract. That solves the tooling problem 
 and the too-much-code problem, no?
No. There is no point of screwing up the language because an arbitrary choice of formating is taking an absurd amount of vertical space.
Feb 04 2015
parent reply "Zach the Mystic" <reachzach gggmail.com> writes:
On Thursday, 5 February 2015 at 07:06:31 UTC, deadalnix wrote:
 On Thursday, 5 February 2015 at 04:36:39 UTC, Zach the Mystic 
 wrote:
 I have an idea. Treat all assert statements which come before 
 the first non-assert statement as part of the 'in' contract. 
 I'm not saying the compiler has to generate a whole 'in' 
 function, but these asserts can be internally tagged to behave 
 *as if* in an 'in' contract. That solves the tooling problem 
 and the too-much-code problem, no?
No. There is no point of screwing up the language because an arbitrary choice of formating is taking an absurd amount of vertical space.
Screwing up the language? I'd be willing to accept your position if I could think of any possible instance in which: T myFunc() assert(xxx); assert(yyy); doStuff(); } ... were not intended to be semantically equivalent to: T myFunc() in { assert(xxx); assert(yyy); } body { doStuff(); } Can you name one, or even imagine one? Bear in mind people like Andrei and myself do not like to read or write the later form and will use it much less, regardless of benefit.
Feb 05 2015
parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Thursday, 5 February 2015 at 16:34:38 UTC, Zach the Mystic 
wrote:
 Can you name one, or even imagine one? Bear in mind people like 
 Andrei and myself do not like to read or write the later form 
 and will use it much less, regardless of benefit.
Daniel Murphy has (function stubs with `assert(0)`), here: http://forum.dlang.org/thread/maud7e$1j3u$1 digitalmars.com?page=7#post-mavf13:24130j:241:40digitalmars.com
Feb 08 2015
parent reply "Zach the Mystic" <reachzach gggmail.com> writes:
On Sunday, 8 February 2015 at 13:03:28 UTC, Marc Schütz wrote:
 On Thursday, 5 February 2015 at 16:34:38 UTC, Zach the Mystic 
 wrote:
 Can you name one, or even imagine one? Bear in mind people 
 like Andrei and myself do not like to read or write the later 
 form and will use it much less, regardless of benefit.
Daniel Murphy has (function stubs with `assert(0)`), here: http://forum.dlang.org/thread/maud7e$1j3u$1 digitalmars.com?page=7#post-mavf13:24130j:241:40digitalmars.com
assert(0) is a special case, and could be easily identified as such. My attitude would be to try to find a way to make this work, according to the principle that the common case should be easy, and the rarer case possible. The difference only applies to what the user is told about when the assert fails, and not the execution semantics themselves - so it's really not "screwing up the language", unless I'm wrong. Also, in Daniel Murphy's example: void func(int x) in { assert(x > 6); // If this assert fails the caller was incorrect } body { assert(x > 7); // If this assert fails then 'func' has a bug. } I don't know how the second assert could men somethign different from the first. If you assert (anything but assert(0)) first thing, you certainly are not checking for bugs *within* the function - you're checking for entry conditions. So the question is whether the practical difference between the two asserts above is sufficient to prevent applying the syntax sugar. I personally can live with it either way (I can handle being told the the function failed when it was really the caller that failed), but it's a judgment call. I mean, this thread was literally called "Another idiom I wish were gone from phobos/druntime." I don't expect it is the last time someone will complain about it.
Feb 08 2015
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Zach the Mystic"  wrote in message 
news:qxtyqdeewrjurmwhksbj forum.dlang.org...

 I don't know how the second assert could men somethign different from the 
 first. If you assert (anything but assert(0)) first thing, you certainly 
 are not checking for bugs *within* the function - you're checking for 
 entry conditions. So the question is whether the practical difference 
 between the two asserts above is sufficient to prevent applying the syntax 
 sugar. I personally can live with it either way (I can handle being told 
 the the function failed when it was really the caller that failed), but 
 it's a judgment call. I mean, this thread was literally called "Another 
 idiom I wish were gone from phobos/druntime." I don't expect it is the 
 last time someone will complain about it.
Here's one: struct S { private: static int instanceCount; ... public: void func(int x) in { assert(x >= 0, "can't call func with negative x"); } body { assert(instanceCount > 0); } } The first assert checks something the caller has control over, the second assert is a sanity check, and if it fails it's not an error in the caller. Anyway, IMO there is zero chance of this making it into the language and you're wasting your energy.
Feb 08 2015
parent "Zach the Mystic" <reachzach gggmail.com> writes:
On Sunday, 8 February 2015 at 17:12:20 UTC, Daniel Murphy wrote:
 "Zach the Mystic"  wrote in message 
 news:qxtyqdeewrjurmwhksbj forum.dlang.org...

 I don't know how the second assert could men somethign 
 different from the first. If you assert (anything but 
 assert(0)) first thing, you certainly are not checking for 
 bugs *within* the function - you're checking for entry 
 conditions. So the question is whether the practical 
 difference between the two asserts above is sufficient to 
 prevent applying the syntax sugar. I personally can live with 
 it either way (I can handle being told the the function failed 
 when it was really the caller that failed), but it's a 
 judgment call. I mean, this thread was literally called 
 "Another idiom I wish were gone from phobos/druntime." I don't 
 expect it is the last time someone will complain about it.
Here's one: struct S { private: static int instanceCount; ... public: void func(int x) in { assert(x >= 0, "can't call func with negative x"); } body { assert(instanceCount > 0); } } The first assert checks something the caller has control over, the second assert is a sanity check, and if it fails it's not an error in the caller.
Well, okay. This is a case where there is a slight practical difference. In the spirit of keeping the rare case possible, I would suggest: body { {} // reject in-contract assert assert(instanceCount > 0); }
 Anyway, IMO there is zero chance of this making it into the 
 language and you're wasting your energy.
That's disappointing, but I didn't waste my energy. I realized there's validity to both sides of this argument (bulky contracts vs. accurate errors), and instead of choosing a side, I tried to come up with the biggest total win for both sides. I think my solution is a 80-90% win for both sides, which is better than 100-0% for just one. If it gets rejected for some other reason, so be it. I'm trying to help, here!
Feb 08 2015
prev sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Wed, 04 Feb 2015 16:43:04 -0800, Andrei Alexandrescu wrote:

 On 2/4/15 4:37 PM, Adam D. Ruppe wrote:
 On Thursday, 5 February 2015 at 00:35:50 UTC, bearophile wrote:
 Contracts can be read by tools, and they are part of the function
 signature. Contracts should be encouraged and increased, not
 discouraged.
I agree. Moreover, if the assert fails in the contract, in theory, we can point the error at the user's code. An assert inside the function is the function's responsibility. An assert in an in contract is the caller's responsibility. They're semantically different (even if dmd treats them the same way)
=20 Yah I concede this is a good point. Yet we're looking at an actual liability and are supposed to look at some vague possible future benefit. -- Andrei
wait, do you mean that there was paradigm shift and we will no more keep=20 shit in the language due to non-existent Jack The Random Reddit User told=20 that he used that shit once? does that mean that typle syntax PR will be=20 accepted, 'cause blocking it is a look at some vague possible future=20 benefit?=
Feb 05 2015
prev sibling parent "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Thursday, 5 February 2015 at 00:37:31 UTC, Adam D. Ruppe wrote:
 On Thursday, 5 February 2015 at 00:35:50 UTC, bearophile wrote:
 Contracts can be read by tools, and they are part of the 
 function signature. Contracts should be encouraged and 
 increased, not discouraged.
I agree. Moreover, if the assert fails in the contract, in theory, we can point the error at the user's code. An assert inside the function is the function's responsibility. An assert in an in contract is the caller's responsibility. They're semantically different (even if dmd treats them the same way)
FWIW (only reading this discussion now, sorry if it has already been stated by someone else), this was also talked about at the Berlin meeting, with the same conclusion. IIRC someone was disappointed that failure on the caller's side to pass correct parameters to a library with contracts caused AssertErrors to be thrown inside the callee, making it seem it was the library's fault.
Feb 08 2015
prev sibling next sibling parent "Tobias Pankrath" <tobias pankrath.net> writes:
On Thursday, 5 February 2015 at 00:35:50 UTC, bearophile wrote:
 Andrei Alexandrescu:

            auto opSlice(size_t low, size_t high)
            in
            {
                assert(low <= high);
            }
            body
            {
                import std.range : take;
                return this[low .. $].take(high - low);
            }
auto opSlice(size_t low, size_t high) in { assert(low <= high); } body { }
Feb 04 2015
prev sibling next sibling parent reply "Jonathan Marler" <johnnymarler gmail.com> writes:
On Thursday, 5 February 2015 at 00:35:50 UTC, bearophile wrote:
 Contracts can be read by tools, and they are part of the 
 function signature. Contracts should be encouraged and 
 increased, not discouraged.

 Bye,
 bearophile
Not to mention that contracts can be removed by the compiler at compile time. i.e. x.opSlice(i, i+1); The assert can be compiled away since i+1 is always >= i. That's one of the great benefits of contracts.
Feb 04 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/4/15 4:40 PM, Jonathan Marler wrote:
 On Thursday, 5 February 2015 at 00:35:50 UTC, bearophile wrote:
 Contracts can be read by tools, and they are part of the function
 signature. Contracts should be encouraged and increased, not discouraged.

 Bye,
 bearophile
Not to mention that contracts can be removed by the compiler at compile time.
Same about asserts. -- Andrei
Feb 04 2015
next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 5 February 2015 at 00:42:01 UTC, Andrei Alexandrescu 
wrote:
 On 2/4/15 4:40 PM, Jonathan Marler wrote:
 On Thursday, 5 February 2015 at 00:35:50 UTC, bearophile wrote:
 Contracts can be read by tools, and they are part of the 
 function
 signature. Contracts should be encouraged and increased, not 
 discouraged.

 Bye,
 bearophile
Not to mention that contracts can be removed by the compiler at compile time.
Same about asserts. -- Andrei
assert run in the callee, in contract SHOULD (but currently don't) run in the caller. That do not create the same optimization opportunities (unless inlining occurs, making the caller and the caller one).
Feb 04 2015
prev sibling parent reply "Jonathan Marler" <johnnymarler gmail.com> writes:
On Thursday, 5 February 2015 at 00:42:01 UTC, Andrei Alexandrescu 
wrote:
 On 2/4/15 4:40 PM, Jonathan Marler wrote:
 On Thursday, 5 February 2015 at 00:35:50 UTC, bearophile wrote:
 Contracts can be read by tools, and they are part of the 
 function
 signature. Contracts should be encouraged and increased, not 
 discouraged.

 Bye,
 bearophile
Not to mention that contracts can be removed by the compiler at compile time.
Same about asserts. -- Andrei
Only if the function is inlined. The function variables are unknown at compile time so there's no way for the function to compile it away (unless the optimizer can see every single call to the function). If you make the caller responsible for the assert then it can determine whether or not it needs to perform it at runtime. Then what about chaining contracts. If a function has an out contract saying that the return value will be between a certain range, and you use that same variable in another function that requires it to be in the same range, you can compile away any assert after the first one. This is trivial to do with contracts. You could do it without contracts I suppose, but would be much more brittle (every single return location would have to have the same assert for example)
Feb 04 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/4/15 4:50 PM, Jonathan Marler wrote:
 On Thursday, 5 February 2015 at 00:42:01 UTC, Andrei Alexandrescu wrote:
 On 2/4/15 4:40 PM, Jonathan Marler wrote:
 On Thursday, 5 February 2015 at 00:35:50 UTC, bearophile wrote:
 Contracts can be read by tools, and they are part of the function
 signature. Contracts should be encouraged and increased, not
 discouraged.

 Bye,
 bearophile
Not to mention that contracts can be removed by the compiler at compile time.
Same about asserts. -- Andrei
Only if the function is inlined.
Non-debug mode removes asserts statically. -- Andrei
Feb 04 2015
next sibling parent reply "David Nadlinger" <code klickverbot.at> writes:
On Thursday, 5 February 2015 at 01:09:15 UTC, Andrei Alexandrescu 
wrote:
 Non-debug mode removes asserts statically. -- Andrei
Using pre-/post-conditions allows the _caller_ to specify whether the checks are run without recompiling the function body, at least in theory. David
Feb 04 2015
parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thursday, February 05, 2015 01:33:54 David Nadlinger via Digitalmars-d wrote:
 On Thursday, 5 February 2015 at 01:09:15 UTC, Andrei Alexandrescu
 wrote:
 Non-debug mode removes asserts statically. -- Andrei
Using pre-/post-conditions allows the _caller_ to specify whether the checks are run without recompiling the function body, at least in theory.
In theory, yes. And then in blocks would provide some value outside of virtual functions. But as it stands, there is _zero_ semantic difference between void foo(int i) in { assert(i > 0); } body { ... } and void foo(int i) { assert(i > 0); ... } And unless we make some serious changes to how D functions are called, I don't see how it could possibly be otherwise. in and out blocks and invariants are not part of the function signature. They're implementation details that disappear when prototypes are used. So, while in principle, it would be great if assertions related to contracts were enabled or disabled by the caller, not only does it not work that way now, I have no idea how it even could work that way. - Jonathan M Davis
Feb 05 2015
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 5 February 2015 at 08:05:30 UTC, Jonathan M Davis 
wrote:
 So, while in principle, it would be great if assertions related 
 to contracts
 were enabled or disabled by the caller, not only does it not 
 work that way
 now, I have no idea how it even could work that way.
You could have an IDE and build system that makes signatures, unit tests and pre/post conditions essentially read only. Then any modifications to the program specification is either impossible or is flagged as something that is up for negotiation. The build system/compiler can trivially emit contracts to a database. If the contracts change then all code that depend on them will have to be revalidated/recompiled. It is important for D that the D developers keep in mind that the language and the compiler should be designed as separate entities. DMD-internals have too much influence over the language design already.
Feb 05 2015
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 5 February 2015 at 08:05:30 UTC, Jonathan M Davis 
wrote:
 On Thursday, February 05, 2015 01:33:54 David Nadlinger via 
 Digitalmars-d wrote:
 On Thursday, 5 February 2015 at 01:09:15 UTC, Andrei 
 Alexandrescu
 wrote:
 Non-debug mode removes asserts statically. -- Andrei
Using pre-/post-conditions allows the _caller_ to specify whether the checks are run without recompiling the function body, at least in theory.
In theory, yes. And then in blocks would provide some value outside of virtual functions. But as it stands, there is _zero_ semantic difference between
DMD is broken. There is no need to break phobos in addition.
Feb 05 2015
prev sibling parent "Dragos Carp" <dragoscarp gmail.com> writes:
On Thursday, 5 February 2015 at 01:09:15 UTC, Andrei Alexandrescu 
wrote:
 On 2/4/15 4:50 PM, Jonathan Marler wrote:
 On Thursday, 5 February 2015 at 00:42:01 UTC, Andrei 
 Alexandrescu wrote:
 On 2/4/15 4:40 PM, Jonathan Marler wrote:
 On Thursday, 5 February 2015 at 00:35:50 UTC, bearophile 
 wrote:
 Contracts can be read by tools, and they are part of the 
 function
 signature. Contracts should be encouraged and increased, not
 discouraged.

 Bye,
 bearophile
Not to mention that contracts can be removed by the compiler at compile time.
Same about asserts. -- Andrei
Only if the function is inlined.
Non-debug mode removes asserts statically. -- Andrei
This is correct only if non-debug mode means -release flag specified. For example the dub documentation is misleading saying that -debug flag enables contracts [1]. The contracts are by default enabled, -release disable them. [1] http://code.dlang.org/package-format#build-options
Feb 05 2015
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/4/15 4:35 PM, bearophile wrote:
 Contracts can be read by tools, and they are part of the function
 signature.
The signature part matters only for overridable functions. I agree the part about tooling has merit. -- Andrei
Feb 04 2015
prev sibling next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 5 February 2015 at 00:24:15 UTC, Andrei Alexandrescu 
wrote:
 I'm seeing another idiom that seems to become fashionable. 
 Consider this excerpt from 
 https://github.com/D-Programming-Language/phobos/blob/master/std/algorithm/iteration.d#L407:

             auto opSlice(size_t low, size_t high)
             in
             {
                 assert(low <= high);
             }
             body
             {
                 import std.range : take;
                 return this[low .. $].take(high - low);
             }

 which of course trivially boils down to:

             auto opSlice(size_t low, size_t high)
             {
                 assert(low <= high);
                 import std.range : take;
                 return this[low .. $].take(high - low);
             }

 What advantage could possibly be in transforming a 5-liner into 
 a 9-liner? Are we really aiming at writing the maximum possible 
 lines of code here and using as many language features as 
 possible everywhere?

 I think we should dust off that Phobos contributors' guide. 
 Sadly, there is little we can do against the more subtle issues.


 Andrei
Various things. 1/ the initial is overly long because the styling is wasteful. void foo() in { ... } body { ... } Is simply one line more than not using contracts. 2/ The semantic is not 100% equivalent (well at least the intended semantic) as the in contract should be chosen based on the static type while the implementation on the dynamic one. That mean the contract should tun in the caller. I don't think this is what DMD does currently, but that is what is intended. See for instance : https://issues.dlang.org/show_bug.cgi?id=12247 https://issues.dlang.org/show_bug.cgi?id=6857
Feb 04 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/4/15 4:47 PM, deadalnix wrote:
 1/ the initial is overly long because the styling is wasteful.

 void foo() in {
    ...
 } body {
    ...
 }

 Is simply one line more than not using contracts.
Would introduce an exception to our brace-on-its-line rule. I need to take issue with "that code is not using contracts". Using assert _is_ using contracts.
 2/ The semantic is not 100% equivalent (well at least the intended
 semantic) as the in contract should be chosen based on the static type
 while the implementation on the dynamic one. That mean the contract
 should tun in the caller.
Yah, I agree "in" is useful for overridable functions. In fact I'd say it's useful _only_ for overridable functions. Andrei
Feb 04 2015
next sibling parent "Jonathan Marler" <johnnymarler gmail.com> writes:
On Thursday, 5 February 2015 at 01:07:56 UTC, Andrei Alexandrescu 
wrote:
 On 2/4/15 4:47 PM, deadalnix wrote:
 1/ the initial is overly long because the styling is wasteful.

 void foo() in {
   ...
 } body {
   ...
 }

 Is simply one line more than not using contracts.
Would introduce an exception to our brace-on-its-line rule. I need to take issue with "that code is not using contracts". Using assert _is_ using contracts.
My definition of an in contract is a condition that the caller is responsible to verify. It appears that your definition is that it's a condition on a function argument (doesn't matter who is responsible). I believe that Walter's definition of Contract programming is the definition I'm referring to. I remember watching one of his talks on contract programming and the performance/optimization benefits he talked about would only apply if a contract made the callee responsible for the asserts. The responsible party, caller/callee matters. As far as I know, D is the first language to allow a function to make the caller responsible for verifying an assert. Even before I saw this in D, I always wondered why no languages provided a way specify this. H.S. Teoh had a good response on why it matters to specify caller/callee so I'll refer to his response instead of re-hashing what he already said.
Feb 04 2015
prev sibling next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 5 February 2015 at 01:07:56 UTC, Andrei Alexandrescu 
wrote:
 Yah, I agree "in" is useful for overridable functions. In fact 
 I'd say it's useful _only_ for overridable functions.
Putting the contract in the caller is not only useful for overridable functions. 1/ If a lib is compiled in without contract, but your code is compiled with, you get the in contract to run when you call library code, but not the assert within the function. 2/ The optimizer see the properties of the argument when they get to the in contract. This information is lost in the callee, unless inlining goes on. that means the amount of contract the optimizer can remove statically is greater with in contract.
Feb 04 2015
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/4/15 5:32 PM, deadalnix wrote:
 On Thursday, 5 February 2015 at 01:07:56 UTC, Andrei Alexandrescu wrote:
 Yah, I agree "in" is useful for overridable functions. In fact I'd say
 it's useful _only_ for overridable functions.
Putting the contract in the caller is not only useful for overridable functions. 1/ If a lib is compiled in without contract, but your code is compiled with, you get the in contract to run when you call library code, but not the assert within the function. 2/ The optimizer see the properties of the argument when they get to the in contract. This information is lost in the callee, unless inlining goes on. that means the amount of contract the optimizer can remove statically is greater with in contract.
Yah, I understand the potential there. Consider me grudgingly convinced :o). -- Andrei
Feb 04 2015
parent reply "Meta" <jared771 gmail.com> writes:
On Thursday, 5 February 2015 at 01:33:54 UTC, Andrei Alexandrescu 
wrote:
 On 2/4/15 5:32 PM, deadalnix wrote:
 On Thursday, 5 February 2015 at 01:07:56 UTC, Andrei 
 Alexandrescu wrote:
 Yah, I agree "in" is useful for overridable functions. In 
 fact I'd say
 it's useful _only_ for overridable functions.
Putting the contract in the caller is not only useful for overridable functions. 1/ If a lib is compiled in without contract, but your code is compiled with, you get the in contract to run when you call library code, but not the assert within the function. 2/ The optimizer see the properties of the argument when they get to the in contract. This information is lost in the callee, unless inlining goes on. that means the amount of contract the optimizer can remove statically is greater with in contract.
Yah, I understand the potential there. Consider me grudgingly convinced :o). -- Andrei
I don't know about others (besides Beatophile, who religiously adheres to writing contacts), but putting contracts on functions is a hassle. I never do it unless I'm feeling particularly full of divine fervor. It's a lot like making all variables that don't need to be changed immutable (another thing which only Bearophile seems to do) or properly documenting code. Strong optimization guarantees from contracts would go a long way in convincing people to actually write them (although I guess that's not what you want; Perhaps you changed your mind). It's a chicken and egg problem.
Feb 04 2015
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Feb 05, 2015 at 05:42:57AM +0000, Meta via Digitalmars-d wrote:
[...]
 I don't know about others (besides Beatophile, who religiously adheres
 to writing contacts), but putting contracts on functions is a hassle.
 I never do it unless I'm feeling particularly full of divine fervor.
 It's a lot like making all variables that don't need to be changed
 immutable (another thing which only Bearophile seems to do) or
 properly documenting code. Strong optimization guarantees from
 contracts would go a long way in convincing people to actually write
 them (although I guess that's not what you want; Perhaps you changed
 your mind). It's a chicken and egg problem.
I do write contracts in my own code, though not as much as I would've because (1) the syntax is far too verbose, (2) dmd makes a mess of DbC by putting in-contracts in the callee rather than the caller, causing severe limitations in real-life usage, and (3) so far optimizations based on contracts (esp. via assert/assume, that Walter was so insistent on) haven't materialized yet. But then again, I do like to document my code a lot too, so maybe I'm just One Of Those People. *shrug* (I'm not as extreme as bearophile in insisting on putting immutable everywhere, though. Not yet, anyway. :-P) T -- Bare foot: (n.) A device for locating thumb tacks on the floor.
Feb 04 2015
next sibling parent reply "Meta" <jared771 gmail.com> writes:
On Thursday, 5 February 2015 at 06:15:39 UTC, H. S. Teoh wrote:
 On Thu, Feb 05, 2015 at 05:42:57AM +0000, Meta via 
 Digitalmars-d wrote:
 [...]
 I don't know about others (besides Beatophile, who religiously 
 adheres
 to writing contacts), but putting contracts on functions is a 
 hassle.
 I never do it unless I'm feeling particularly full of divine 
 fervor.
 It's a lot like making all variables that don't need to be 
 changed
 immutable (another thing which only Bearophile seems to do) or
 properly documenting code. Strong optimization guarantees from
 contracts would go a long way in convincing people to actually 
 write
 them (although I guess that's not what you want; Perhaps you 
 changed
 your mind). It's a chicken and egg problem.
I do write contracts in my own code, though not as much as I would've because (1) the syntax is far too verbose, (2) dmd makes a mess of DbC by putting in-contracts in the callee rather than the caller, causing severe limitations in real-life usage, and (3) so far optimizations based on contracts (esp. via assert/assume, that Walter was so insistent on) haven't materialized yet. But then again, I do like to document my code a lot too, so maybe I'm just One Of Those People. *shrug* (I'm not as extreme as bearophile in insisting on putting immutable everywhere, though. Not yet, anyway. :-P) T
I've found that the more years of experience I have under my belt, the less documentation I wrote. When I was starting out I was very diligent in doing everything the Correct Way so as to cultivate good habits. I'd find my regression over the years more alarming if I cared enough.
Feb 04 2015
parent reply "Vlad Levenfeld" <vlevenfeld gmail.com> writes:
On Thursday, 5 February 2015 at 06:26:17 UTC, Meta wrote:
 I've found that the more years of experience I have under my 
 belt, the less documentation I wrote. When I was starting out I 
 was very diligent in doing everything the Correct Way so as to 
 cultivate good habits. I'd find my regression over the years 
 more alarming if I cared enough.
$0.02: I personally use contracts quite a lot to tighten the screws on my interfaces. I don't like writing documentation, mostly on account of I refactor so aggressively it winds up being wasted effort in a lot of cases (though I do make notes when I think something is complex enough to forget or unlikely to change), so instead I opt to "document" via unittest and assert messages in contracts. One of my main internal packages consists of a set of mixin templates that generate operators from supplied primitives. The release runtime is meant to be light, and mostly offers syntactic sugar (more importantly, unified interfaces with predictable semantics) so code for each layer winds up being between 1:1 and 60:1 contract to body. From a documentation perspective, being able to open up the "out" block and see that the enclosing struct's length values must reflect the values passed to the allocation primitive is nice. Being able to open up the "body" block and see, without the clutter of all the bounds checks and whatnot, opIndex just forwards the call to the access primitive in one line - also nice. I love dbC in D. I think in/out makes things clean and obvious. I could care less about the line count, I use code-folding anyway.
Feb 04 2015
parent reply "Vlad Levenfeld" <vlevenfeld gmail.com> writes:
On Thursday, 5 February 2015 at 06:51:35 UTC, Vlad Levenfeld 
wrote:
 I could care less
Er, stupid but unfortunately common american english idiom. For non-native speakers, I mean to say I could NOT care less.
Feb 04 2015
parent reply "eles" <eles eles.com> writes:
On Thursday, 5 February 2015 at 06:55:09 UTC, Vlad Levenfeld 
wrote:
 On Thursday, 5 February 2015 at 06:51:35 UTC, Vlad Levenfeld 
 wrote:
 I could care less
Er, stupid but unfortunately common american english idiom. For
Thanks. I was firmly convinced that's a typo...
Feb 05 2015
parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thursday, February 05, 2015 08:13:32 eles via Digitalmars-d wrote:
 On Thursday, 5 February 2015 at 06:55:09 UTC, Vlad Levenfeld
 wrote:
 On Thursday, 5 February 2015 at 06:51:35 UTC, Vlad Levenfeld
 wrote:
 I could care less
Er, stupid but unfortunately common american english idiom. For
Thanks. I was firmly convinced that's a typo...
No. It's just a frustratingly common mistake - like saying "for all intensive purposes" instead of "for all intents and purposes." Unfortunately, many folks couldn't care less about getting it right... - Jonathan M Davis
Feb 05 2015
next sibling parent "Vlad Levenfeld" <vlevenfeld gmail.com> writes:
On Thursday, 5 February 2015 at 08:22:24 UTC, Jonathan M Davis 
wrote:
 No. It's just a frustratingly common mistake - like saying "for 
 all
 intensive purposes" instead of "for all intents and purposes."
 Unfortunately, many folks couldn't care less about getting it 
 right...
Well, when you grow up hearing it, you reach for the notion and the words just come out before you can apply the filter. Irregardless, same difference.
Feb 05 2015
prev sibling next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On 2/5/2015 5:22 PM, Jonathan M Davis via Digitalmars-d wrote:
 On Thursday, February 05, 2015 08:13:32 eles via Digitalmars-d wrote:
 On Thursday, 5 February 2015 at 06:55:09 UTC, Vlad Levenfeld
 wrote:
 On Thursday, 5 February 2015 at 06:51:35 UTC, Vlad Levenfeld
 wrote:
 I could care less
Er, stupid but unfortunately common american english idiom. For
Thanks. I was firmly convinced that's a typo...
No. It's just a frustratingly common mistake - like saying "for all intensive purposes" instead of "for all intents and purposes." Unfortunately, many folks couldn't care less about getting it right... - Jonathan M Davis
I can't phantom that!
Feb 05 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/5/15 5:47 AM, Mike Parker wrote:
 On 2/5/2015 5:22 PM, Jonathan M Davis via Digitalmars-d wrote:
 On Thursday, February 05, 2015 08:13:32 eles via Digitalmars-d wrote:
 On Thursday, 5 February 2015 at 06:55:09 UTC, Vlad Levenfeld
 wrote:
 On Thursday, 5 February 2015 at 06:51:35 UTC, Vlad Levenfeld
 wrote:
 I could care less
Er, stupid but unfortunately common american english idiom. For
Thanks. I was firmly convinced that's a typo...
No. It's just a frustratingly common mistake - like saying "for all intensive purposes" instead of "for all intents and purposes." Unfortunately, many folks couldn't care less about getting it right... - Jonathan M Davis
I can't phantom that!
I think we should return to the topic at hand irregardless. -- Andrei
Feb 05 2015
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/5/2015 12:22 AM, Jonathan M Davis via Digitalmars-d wrote:
 No. It's just a frustratingly common mistake - like saying "for all
 intensive purposes" instead of "for all intents and purposes."
What? I thought it was "for all infants and porpoises"!
Feb 05 2015
next sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Feb 05, 2015 at 12:03:29PM -0800, Walter Bright via Digitalmars-d wrote:
 On 2/5/2015 12:22 AM, Jonathan M Davis via Digitalmars-d wrote:
No. It's just a frustratingly common mistake - like saying "for all
intensive purposes" instead of "for all intents and purposes."
What? I thought it was "for all infants and porpoises"!
What, what? For elephants and porpoises? I thought this was a programming language forum; I must have subscribed to a zoo magazine by mistake! T -- Programming is not just an act of telling a computer what to do: it is also an act of telling other programmers what you wished the computer to do. Both are important, and the latter deserves care. -- Andrew Morton
Feb 05 2015
prev sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thursday, February 05, 2015 12:03:29 Walter Bright via Digitalmars-d wrote:
 On 2/5/2015 12:22 AM, Jonathan M Davis via Digitalmars-d wrote:
 No. It's just a frustratingly common mistake - like saying "for all
 intensive purposes" instead of "for all intents and purposes."
What? I thought it was "for all infants and porpoises"!
LOL. - Jonathan M Davis
Feb 05 2015
prev sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Thursday, 5 February 2015 at 06:15:39 UTC, H. S. Teoh wrote:
 On Thu, Feb 05, 2015 at 05:42:57AM +0000, Meta via 
 Digitalmars-d wrote:
 [...]
 I don't know about others (besides Beatophile, who religiously 
 adheres
 to writing contacts), but putting contracts on functions is a 
 hassle.
 I never do it unless I'm feeling particularly full of divine 
 fervor.
 It's a lot like making all variables that don't need to be 
 changed
 immutable (another thing which only Bearophile seems to do) or
 properly documenting code. Strong optimization guarantees from
 contracts would go a long way in convincing people to actually 
 write
 them (although I guess that's not what you want; Perhaps you 
 changed
 your mind). It's a chicken and egg problem.
I do write contracts in my own code, though not as much as I would've because (1) the syntax is far too verbose, (2) dmd makes a mess of DbC by putting in-contracts in the callee rather than the caller, causing severe limitations in real-life usage, and (3) so far optimizations based on contracts (esp. via assert/assume, that Walter was so insistent on) haven't materialized yet. But then again, I do like to document my code a lot too, so maybe I'm just One Of Those People. *shrug* (I'm not as extreme as bearophile in insisting on putting immutable everywhere, though. Not yet, anyway. :-P) T
I miss the point about in. DbC as presentend by Eiffel and adopted in .NET, Ada among others, the complete contract is on the callee. It doesn't make sense otherwise.
Feb 04 2015
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 5 February 2015 at 07:28:36 UTC, Paulo Pinto wrote:
 I miss the point about in.

 DbC as presentend by Eiffel and adopted in .NET, Ada among 
 others, the complete contract is on the  callee.

 It doesn't make sense otherwise.
Conceptually the precondition is a specification that the caller has to guarantee, and the postcondition is a specification that the callee guarantees. The enforcement of the contract specification should be done by the build system which is "neutral". I.e. the contractors who wrote the code for the callers and callees may try to subvert the contract, but the build system should ideally prevent this. This is of course messed up in D, since you don't have a separate specification independent of the implementation, but you could still verify the D code against a specification to prevent contractors from subverting contracts. The thought of having the signature/specification before the implementation was a good one, but readability suffers from having all the braces. So the D syntax is not as usable as it should be. I think D should do this in the body like other languages: func(){ require(...); ensure(…); ... function body ... } or func(){ pre(...); post(…); ... function body ... } or func(){ pre_assert(...); post_assert(…); ... function body ... }
Feb 04 2015
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 5 February 2015 at 07:28:36 UTC, Paulo Pinto wrote:
 I miss the point about in.

 DbC as presentend by Eiffel and adopted in .NET, Ada among 
 others, the complete contract is on the  callee.

 It doesn't make sense otherwise.
There was a huge discussion here: https://issues.dlang.org/show_bug.cgi?id=6857 Long story short: it was done in Eiffel that way for implementation reason, other language are cargo culting eiffel, and putting in contract in the caller is the right thing to do.
Feb 05 2015
next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Thursday, 5 February 2015 at 09:02:05 UTC, deadalnix wrote:
 On Thursday, 5 February 2015 at 07:28:36 UTC, Paulo Pinto wrote:
 I miss the point about in.

 DbC as presentend by Eiffel and adopted in .NET, Ada among 
 others, the complete contract is on the  callee.

 It doesn't make sense otherwise.
There was a huge discussion here: https://issues.dlang.org/show_bug.cgi?id=6857 Long story short: it was done in Eiffel that way for implementation reason, other language are cargo culting eiffel, and putting in contract in the caller is the right thing to do.
So the caller can break the contract without any consideration for what values the input arguments are valid?! There is a reason why the industry at large has adopted the Eiffel way. - Paulo
Feb 05 2015
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 5 February 2015 at 09:33:12 UTC, Paulo  Pinto wrote:
 So the caller can break the contract without any consideration 
 for what values the input arguments are valid?!

 There is a reason why the industry at large has adopted the 
 Eiffel way.
Yes, it is called cargo cult.
Feb 05 2015
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Thursday, 5 February 2015 at 10:09:34 UTC, deadalnix wrote:
 On Thursday, 5 February 2015 at 09:33:12 UTC, Paulo  Pinto 
 wrote:
 So the caller can break the contract without any consideration 
 for what values the input arguments are valid?!

 There is a reason why the industry at large has adopted the 
 Eiffel way.
Yes, it is called cargo cult.
I am out.
Feb 05 2015
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 5 February 2015 at 11:05:42 UTC, Paulo  Pinto wrote:
 On Thursday, 5 February 2015 at 10:09:34 UTC, deadalnix wrote:
 On Thursday, 5 February 2015 at 09:33:12 UTC, Paulo  Pinto 
 wrote:
 So the caller can break the contract without any 
 consideration for what values the input arguments are valid?!

 There is a reason why the industry at large has adopted the 
 Eiffel way.
Yes, it is called cargo cult.
I am out.
Out of the rabbit hole, like Alice in Wonderland? But you are right, of course. The caller should not be able to subvert the contract. Only the build system should control contract enforcement (e.g. the integration team, system architect etc, not implementors) The D design process is very much a cargo cult thing...
Feb 05 2015
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Thursday, 5 February 2015 at 11:43:28 UTC, Ola Fosheim Grøstad 
wrote:
 On Thursday, 5 February 2015 at 11:05:42 UTC, Paulo  Pinto 
 wrote:
 On Thursday, 5 February 2015 at 10:09:34 UTC, deadalnix wrote:
 On Thursday, 5 February 2015 at 09:33:12 UTC, Paulo  Pinto 
 wrote:
 So the caller can break the contract without any 
 consideration for what values the input arguments are valid?!

 There is a reason why the industry at large has adopted the 
 Eiffel way.
Yes, it is called cargo cult.
I am out.
Out of the rabbit hole, like Alice in Wonderland? But you are right, of course. The caller should not be able to subvert the contract. Only the build system should control contract enforcement (e.g. the integration team, system architect etc, not implementors) The D design process is very much a cargo cult thing...
I believe the Eiffel way, just like the industry does, with endless tools and processes that follow and validate DbC. Since I don't have any use for D at work, besides being a language geek, I don't see the point to argue for whatever might be the outcome, other than producing noise and being part of the problem. So, I am out of this thread. -- Paulo
Feb 05 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 5 February 2015 at 12:39:18 UTC, Paulo  Pinto wrote:
 I believe the Eiffel way, just like the industry does, with 
 endless tools
 and processes that follow and validate DbC.
I believe Ada allows the separation of interface and implementation, and providing the contract in the interface. So it is less dependent on tools. Ada with SPARK 2014 makes D look like it is stuck in the 80s: 4.2. Subprogram Contracts 4.2.1. Preconditions 4.2.2. Postconditions 4.2.3. Contract Cases 4.2.4. Data Dependencies 4.2.5. Flow Dependencies 4.2.6. State Abstraction and Contracts 4.2.6.1. State Abstraction and Dependencies 4.2.6.2. State Abstraction and Functional Contracts 4.3. Package Contracts 4.3.1. State Abstraction 4.3.2. Package Initialization 4.3.3. Package Initial Condition 4.3.4. Interfaces to the Physical World 4.3.4.1. Volatile Variables 4.3.4.2. Flavors of Volatile Variables 4.3.4.3. External State Abstraction 4.4. Type Contracts 4.4.1. Scalar Ranges 4.4.2. Static Predicates 4.4.3. Record Discriminants 4.4.4. Default Initial Condition 4.5. Specification Features 4.5.1. Attribute Old 4.5.1.1. In a Postcondition 4.5.1.2. In Contract Cases 4.5.1.3. In a Potentially Unevaluated Expression 4.5.2. Attribute Result 4.5.3. Attribute Loop_Entry 4.5.4. Attribute Update 4.5.5. Conditional Expressions 4.5.6. Quantified Expressions 4.5.7. Expression Functions 4.5.8. Ghost Code 4.5.8.1. Ghost Functions 4.5.8.2. Ghost Variables Case 1: Keeping Intermediate Values Case 2: Keeping Memory of Previous State Case 3: Logging Previous Events 4.5.8.3. Ghost Types 4.5.8.4. Ghost Procedures 4.5.8.5. Ghost Packages 4.5.8.6. Imported Ghost Subprograms 4.6. Assertion Pragmas 4.6.1. Pragma Assert 4.6.2. Loop Invariants 4.6.3. Loop Variants 4.6.4. Pragma Assume 4.6.5. Pragma Assert_And_Cut Yep, D has some serious competition in systems programming and this is just extensions to an old pragmatic language... there are probably more advanced stuff waiting to coming out of research languages...
Feb 05 2015
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Ola Fosheim Grøstad:

 Ada with SPARK 2014 makes D look like it is stuck in the 80s:

 4.2. Subprogram Contracts
 4.2.1. Preconditions
 4.2.2. Postconditions
 4.2.3. Contract Cases
 4.2.4. Data Dependencies
 4.2.5. Flow Dependencies
 4.2.6. State Abstraction and Contracts
 4.2.6.1. State Abstraction and Dependencies
 4.2.6.2. State Abstraction and Functional Contracts
 4.3. Package Contracts
 4.3.1. State Abstraction
 4.3.2. Package Initialization
 4.3.3. Package Initial Condition
 4.3.4. Interfaces to the Physical World
 4.3.4.1. Volatile Variables
 4.3.4.2. Flavors of Volatile Variables
 4.3.4.3. External State Abstraction
 4.4. Type Contracts
 4.4.1. Scalar Ranges
 4.4.2. Static Predicates
 4.4.3. Record Discriminants
 4.4.4. Default Initial Condition
 4.5. Specification Features
 4.5.1. Attribute Old
 4.5.1.1. In a Postcondition
 4.5.1.2. In Contract Cases
 4.5.1.3. In a Potentially Unevaluated Expression
 4.5.2. Attribute Result
 4.5.3. Attribute Loop_Entry
 4.5.4. Attribute Update
 4.5.5. Conditional Expressions
 4.5.6. Quantified Expressions
 4.5.7. Expression Functions
 4.5.8. Ghost Code
 4.5.8.1. Ghost Functions
 4.5.8.2. Ghost Variables
 Case 1: Keeping Intermediate Values
 Case 2: Keeping Memory of Previous State
 Case 3: Logging Previous Events
 4.5.8.3. Ghost Types
 4.5.8.4. Ghost Procedures
 4.5.8.5. Ghost Packages
 4.5.8.6. Imported Ghost Subprograms
 4.6. Assertion Pragmas
 4.6.1. Pragma Assert
 4.6.2. Loop Invariants
 4.6.3. Loop Variants
 4.6.4. Pragma Assume
 4.6.5. Pragma Assert_And_Cut
That seems a bit too much for the average human to handle :-) Sometimes features help, but that list seems excessive for a language that is not meant for high integrity systems as D. Bye, bearophile
Feb 06 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 6 February 2015 at 10:08:29 UTC, bearophile wrote:
 That seems a bit too much for the average human to handle :-)
 Sometimes features help, but that list seems excessive for a 
 language that is not meant for high integrity systems as D.
So D has to decide what development scenario it wants to compete in. There are advanced competitive alternatives for specific system development scenarios with C-like performance. A wide partial feature set only impress programmers who don't know the field, but underwhelm those who actually look for a particular feature set. Having 70% coverage of what the competitors provide for a development scenario is not good enough. D feature set currently does not cut it in: - interactive/realtime - low memory usage/manual memory management - numeric analysis/SIMD - verification - high concurrency/low latency - dataflow/reactive - hardware programming/no runtime/intrinsics - system integration (xml etc) - rapid prototyping - native gui applications So where is D going to make a dent? If you want safer C-like programming you are up against: - various C platforms/tooling - C++14, advanced tooling (analysis, instrumentation), MPX - Ada/SPARK 2014 - Rust If safe/ trusted/ system is not the main selling point for D then it has to provide one of the others. E.g. easy SIMD, unique_ptr style memory management etc.
Feb 06 2015
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 5 February 2015 at 11:05:42 UTC, Paulo  Pinto wrote:
 On Thursday, 5 February 2015 at 10:09:34 UTC, deadalnix wrote:
 On Thursday, 5 February 2015 at 09:33:12 UTC, Paulo  Pinto 
 wrote:
 So the caller can break the contract without any 
 consideration for what values the input arguments are valid?!

 There is a reason why the industry at large has adopted the 
 Eiffel way.
Yes, it is called cargo cult.
I am out.
To be frankly brutal, you were never in. You presented no argument.
Feb 05 2015
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Thursday, 5 February 2015 at 17:32:23 UTC, deadalnix wrote:
 On Thursday, 5 February 2015 at 11:05:42 UTC, Paulo  Pinto 
 wrote:
 On Thursday, 5 February 2015 at 10:09:34 UTC, deadalnix wrote:
 On Thursday, 5 February 2015 at 09:33:12 UTC, Paulo  Pinto 
 wrote:
 So the caller can break the contract without any 
 consideration for what values the input arguments are valid?!

 There is a reason why the industry at large has adopted the 
 Eiffel way.
Yes, it is called cargo cult.
I am out.
To be frankly brutal, you were never in. You presented no argument.
I did, by stating that the way Eiffel does is how it is supposed to be. Also mentioned that by giving the callers control over pre-conditions is breaking the notion of what Design by Contract stands for. If the caller can disable pre-conditions of the callee, then the premisses of Design by Contract just go out of the window. I was dry with my statement, because by calling the verification industry as cargo cultists, I could only depreend no argument on my side would change your opinion. As far as I can tell, D in production doesn't even reach 1% of production systems out there coded in Eiffel, Ada 2012, .NET Code Contracts, Spec# and Dafny uses at MSR, Dbc at NASA, Dbc at Lockheed Martin and so on, wherever it is used. Yet, here goes the discussion against what production quality systems have been delivering because they are all wrong and its developers are plain cargo cultists. Anyway, as a simple D dabbler I should learn to keep quiet, as I am just adding noise to the NG. -- Paulo
Feb 05 2015
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/5/15 11:19 AM, Paulo Pinto wrote:
 I did, by stating that the way Eiffel does is how it is supposed to be.
That issue reveals that Eiffel essentially contradicts directly its creators' book. -- Andrei
Feb 05 2015
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 5 February 2015 at 19:19:43 UTC, Paulo Pinto wrote:
 To be frankly brutal, you were never in. You presented no 
 argument.
I did, by stating that the way Eiffel does is how it is supposed to be.
In the links that were provided to you, you'll see one instance of Eiffel's designer saying that this was done like this at first for ease of implementation and then it stated like this for historical reason, and that the sensible thing to do is to put the check in the caller. No, if you want to say that Eiffel is the way it should, while even its creator think this is not the case, you have to substantiate. Saying that Eiffel do it in some way is certainly a fact, but not an argument.
 I was dry with my statement, because by calling the 
 verification industry as cargo cultists, I could only depreend 
 no argument on my side would change your opinion.
In fact this is very possible to change my opinion. If you read the bug report, you'll notice that I'm defending a position similar to yours at first. Considering that someone who contradict you cannot be convinced anyway is a lazy. I'm not changing my position because no new argument have been presented.
Feb 05 2015
prev sibling parent reply "eles" <eles eles.com> writes:
On Thursday, 5 February 2015 at 09:02:05 UTC, deadalnix wrote:
 On Thursday, 5 February 2015 at 07:28:36 UTC, Paulo Pinto wrote:
 I miss the point about in.

 DbC as presentend by Eiffel and adopted in .NET, Ada among 
 others, the complete contract is on the  callee.

 It doesn't make sense otherwise.
There was a huge discussion here: https://issues.dlang.org/show_bug.cgi?id=6857
Wow. Amazing discussion.
Feb 05 2015
parent reply "eles" <eles eles.com> writes:
On Thursday, 5 February 2015 at 10:51:32 UTC, eles wrote:
 On Thursday, 5 February 2015 at 09:02:05 UTC, deadalnix wrote:
 On Thursday, 5 February 2015 at 07:28:36 UTC, Paulo Pinto 
 wrote:
 I miss the point about in.

 DbC as presentend by Eiffel and adopted in .NET, Ada among 
 others, the complete contract is on the  callee.

 It doesn't make sense otherwise.
There was a huge discussion here: https://issues.dlang.org/show_bug.cgi?id=6857
Wow. Amazing discussion.
But it ends with: "Andrei Alexandrescu 2013-01-10 09:14:02 UTC Walter: would you preapprove this?" Well, we are now 2 years (and some) later.
Feb 05 2015
next sibling parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"eles"  wrote in message news:sybluuitxifnwrwzgbpo forum.dlang.org...

 But it ends with:

 "Andrei Alexandrescu 2013-01-10 09:14:02 UTC
  Walter: would you preapprove this?"

 Well, we are now 2 years (and some) later.
I don't speak for Walter, but I expect if it can be implemented in a sane way it will make it into the compiler and spec.
Feb 05 2015
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/5/15 2:55 AM, eles wrote:
 On Thursday, 5 February 2015 at 10:51:32 UTC, eles wrote:
 On Thursday, 5 February 2015 at 09:02:05 UTC, deadalnix wrote:
 On Thursday, 5 February 2015 at 07:28:36 UTC, Paulo Pinto wrote:
 I miss the point about in.

 DbC as presentend by Eiffel and adopted in .NET, Ada among others,
 the complete contract is on the  callee.

 It doesn't make sense otherwise.
There was a huge discussion here: https://issues.dlang.org/show_bug.cgi?id=6857
Wow. Amazing discussion.
But it ends with: "Andrei Alexandrescu 2013-01-10 09:14:02 UTC Walter: would you preapprove this?" Well, we are now 2 years (and some) later.
It has been preapproved. The challenge now is implementing it. -- Andrei
Feb 05 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/5/15 9:31 AM, Andrei Alexandrescu wrote:
 On 2/5/15 2:55 AM, eles wrote:
 On Thursday, 5 February 2015 at 10:51:32 UTC, eles wrote:
 On Thursday, 5 February 2015 at 09:02:05 UTC, deadalnix wrote:
 On Thursday, 5 February 2015 at 07:28:36 UTC, Paulo Pinto wrote:
 I miss the point about in.

 DbC as presentend by Eiffel and adopted in .NET, Ada among others,
 the complete contract is on the  callee.

 It doesn't make sense otherwise.
There was a huge discussion here: https://issues.dlang.org/show_bug.cgi?id=6857
Wow. Amazing discussion.
But it ends with: "Andrei Alexandrescu 2013-01-10 09:14:02 UTC Walter: would you preapprove this?" Well, we are now 2 years (and some) later.
It has been preapproved. The challenge now is implementing it. -- Andrei
Better put: it had been preapproved back in Jan 2013 and is still looking for someone to fix it. -- Andrei
Feb 05 2015
prev sibling next sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Meta"  wrote in message news:ejqtxksoifmqzetllaqw forum.dlang.org...

 I don't know about others (besides Beatophile, who religiously adheres to 
 writing contacts), but putting contracts on functions is a hassle. I never 
 do it unless I'm feeling particularly full of divine fervor. It's a lot 
 like making all variables that don't need to be changed immutable (another 
 thing which only Bearophile seems to do) or properly documenting code. 
 Strong optimization guarantees from contracts would go a long way in 
 convincing people to actually write them (although I guess that's not what 
 you want; Perhaps you changed your mind). It's a chicken and egg problem.
Would you be more likely to write contracts if something like this was implemented? https://github.com/D-Programming-Language/dmd/pull/3799 I want to check contracts at compile time, when possible. For me this would make contracts 1000x more useful.
Feb 04 2015
next sibling parent reply "Meta" <jared771 gmail.com> writes:
On Thursday, 5 February 2015 at 06:41:59 UTC, Daniel Murphy wrote:
 "Meta"  wrote in message 
 news:ejqtxksoifmqzetllaqw forum.dlang.org...

 I don't know about others (besides Beatophile, who religiously 
 adheres to writing contacts), but putting contracts on 
 functions is a hassle. I never do it unless I'm feeling 
 particularly full of divine fervor. It's a lot like making all 
 variables that don't need to be changed immutable (another 
 thing which only Bearophile seems to do) or properly 
 documenting code. Strong optimization guarantees from 
 contracts would go a long way in convincing people to actually 
 write them (although I guess that's not what you want; Perhaps 
 you changed your mind). It's a chicken and egg problem.
Would you be more likely to write contracts if something like this was implemented? https://github.com/D-Programming-Language/dmd/pull/3799 I want to check contracts at compile time, when possible. For me this would make contracts 1000x more useful.
I have seen that PR previously, and I do hope it gets merged. It is a step in the right direction; contracts may turn out to be a veritable goldmine of opportunities from optimization, such as Walter's desire to have assert() also mean assume(). Using contracts for optimization purposes is really a win-win, as it would make contract-based code both more correct AND faster. I think the best way to evangelize DbC is not that it's the correct thing to do, but because it makes code faster. That's obviously not the case with D yet, but I hope we get there someday.
Feb 05 2015
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Meta"  wrote in message news:etibhdbtswksyksznfxv forum.dlang.org...

 I have seen that PR previously, and I do hope it gets merged. It is a step 
 in the right direction; contracts may turn out to be a veritable goldmine 
 of opportunities from optimization, such as Walter's desire to have 
 assert() also mean assume(). Using contracts for optimization purposes is 
 really a win-win, as it would make contract-based code both more correct 
 AND faster. I think the best way to evangelize DbC is not that it's the 
 correct thing to do, but because it makes code faster. That's obviously 
 not the case with D yet, but I hope we get there someday.
Yes, optimization is another nice possibility. I think there is a lot of untapped potential in using contracts to pass extra information to the compiler.
Feb 05 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/5/15 1:53 AM, Daniel Murphy wrote:
 Yes, optimization is another nice possibility.  I think there is a lot
 of untapped potential in using contracts to pass extra information to
 the compiler.
I agree. One actionable - albeit crazy :o) - idea is to make __FILE__, __LINE__, __MODULE__ etc. inside contracts bind to the caller context. Then all failures blame straight to the caller code. -- Andrei
Feb 05 2015
parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Andrei Alexandrescu"  wrote in message 
news:mb03nt$1lhr$1 digitalmars.com...

 I agree. One actionable - albeit crazy :o) - idea is to make __FILE__, 
 __LINE__, __MODULE__ etc. inside contracts bind to the caller context. 
 Then all failures blame straight to the caller code. -- Andrei
Unfortunately that's not practical until contracts have been changed to run from the caller's side, as there is no way to pass them through the called function without modifying its argument list. #3799 does however report the caller's location correctly.
Feb 05 2015
prev sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thursday, February 05, 2015 17:42:11 Daniel Murphy via Digitalmars-d wrote:
 "Meta"  wrote in message news:ejqtxksoifmqzetllaqw forum.dlang.org...

 I don't know about others (besides Beatophile, who religiously adheres to
 writing contacts), but putting contracts on functions is a hassle. I never
 do it unless I'm feeling particularly full of divine fervor. It's a lot
 like making all variables that don't need to be changed immutable (another
 thing which only Bearophile seems to do) or properly documenting code.
 Strong optimization guarantees from contracts would go a long way in
 convincing people to actually write them (although I guess that's not what
 you want; Perhaps you changed your mind). It's a chicken and egg problem.
Would you be more likely to write contracts if something like this was implemented? https://github.com/D-Programming-Language/dmd/pull/3799 I want to check contracts at compile time, when possible. For me this would make contracts 1000x more useful.
If the semantics of auto foo(T arg) in { assert(something about arg); } body { ... } and auto foo(T arg) { assert(something about arg); ... } actually are different, and the in block provides a useful difference, then there's value in having in blocks. Without that, IMHO, they're just visual noise, even if you use a different coding style that condenses them more, e.g. auto foo(T arg) in { assert(something about arg); } body { ... } So, if we can change the semantics of in and out blocks so that they provide actual value, then there's definitely value in using them. But until then, as far as I'm concerned, they're just cruft that should be avoided. Having some sort of compile time checking of contracts would potentally be a case where in blocks would be of value, though I really don't see much difference between checking the assertions in an in block and checking any other assertions at compile time that can be checked at compile time - especially if they're at the beginning of a function. The real killer feature would be if we could figure out how to make it so that contracts are controlled by the call site instead of being compiled out when the function itself is compiled without assertions enabled. But I have no idea how we could do that given that we can have function prototypes without the actual source code being visible at the call site. - Jonathan M Davis
Feb 05 2015
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 5 February 2015 at 08:25:56 UTC, Jonathan M Davis 
wrote:
 case where in blocks would be of value, though I really don't 
 see much
 difference between checking the assertions in an in block and 
 checking any
 other assertions at compile time that can be checked at compile 
 time -
The difference is that implementation asserts() are part of debugging within a module, while contracts may be active in release mode so that you know which module failed and which subcontractor to call to fix it.
Feb 05 2015
parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thursday, February 05, 2015 08:31:08 via Digitalmars-d wrote:
 On Thursday, 5 February 2015 at 08:25:56 UTC, Jonathan M Davis
 wrote:
 case where in blocks would be of value, though I really don't
 see much
 difference between checking the assertions in an in block and
 checking any
 other assertions at compile time that can be checked at compile
 time -
The difference is that implementation asserts() are part of debugging within a module, while contracts may be active in release mode so that you know which module failed and which subcontractor to call to fix it.
There is no such difference in the current implementation. assertions inside of in and out blocks are no different from assertions inside of the functions themselves with regards to when they are compiled in or not. The _only_ difference between having an assertion inside of an in block and having it at the beginning of the function is that if the function is a virtual function, then the rules of inheritance of DbC are taken into account, which IIRC means that only one of the functions in the inheritance chain has to have its in block pass, and the others are allowed to fail, whereas if it were an out block, all of them would have to pass. Regardless, if you have auto foo(T t) in { assert(something about t); } body { ... } it's _identical_ to auto foo(T t) { assert(something about t); ... } with regards to semantics. Ideally, what's in the in block would be compiled in if the caller is compiled with assertions enabled with no regard to whether the library with foo in it was compiled with assertions enabled or not, but that's not how it works. And because D allows for function prototypes where the implementation is hidden, it's not at all obvious how it would even be possible for anything in an in our out block could be compiled in or not based on the caller rather than the function itself. - Jonathan M Davis
Feb 05 2015
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 5 February 2015 at 09:43:53 UTC, Jonathan M Davis 
wrote:
 There is no such difference in the current implementation. 
 assertions inside
 of in and out blocks are no different from assertions inside of 
 the
 functions themselves with regards to when they are compiled in 
 or not.
But that is a compiler issue, and not a general issue with interface contracts for components. What is desirable is to have "asserts with semantics attached to them" done in a way that works with how you do formal program verification. I also would like to see loop invariants getting a special treatment.
 pass. Regardless,
 if you have

 auto foo(T t)
 in
 {
     assert(something about t);
 }
 body
 {
     ...
 }

 it's _identical_ to

 auto foo(T t)
 {
     assert(something about t);
     ...
 }
Yes and just having an alias "precondition" for "assert" would go a long way in that case. And if the compiler recognize it, it could also do the magic for inheritance.
 with regards to semantics. Ideally, what's in the in block 
 would be compiled
 in if the caller is compiled with assertions enabled with no 
 regard to
 whether the library with foo in it was compiled with assertions 
 enabled or
 not, but that's not how it works. And because D allows for 
 function
 prototypes where the implementation is hidden, it's not at all 
 obvious how
 it would even be possible for anything in an in our out block 
 could be
 compiled in or not based on the caller rather than the function 
 itself.
I actually think that interface contracts (and ideally unit tests) should be part of a specification language that is shared across implementation languages. Then the implementation language has to provide mechanisms to make it possible to test that the transitions between components abide interface contracts. The ideal build system would allow you to have one specification with pre/post conditions between modules and then let the build system link together "LLVM IRish object code" with checks between modules injected duing whole program optimized "linking". That way you could build large systems that are more robust using code from C, C++, Ada, Fortran, Rust, D... governed by one unified specification. And a combination of proof verification and an optimizing linker could elide pre/post-condition tests that are redundant, either before a formal proof exists that only needs to be verified or because the condition is trivially satisifie, e.g.: ---- func(int i){ precondition(i>0); ... } ---- func(3); -----
Feb 05 2015
prev sibling parent reply "Kagamin" <spam here.lot> writes:
On Thursday, 5 February 2015 at 09:43:53 UTC, Jonathan M Davis 
wrote:
 There is no such difference in the current implementation. 
 assertions inside
 of in and out blocks are no different from assertions inside of 
 the
 functions themselves with regards to when they are compiled in 
 or not.
Good point. One problem is that base asserts throw exceptions on loosening contract on overriding method. Asserts in contracts can behave differently, e.g. derived contract can call base contract with a parameter asking to not throw on failure.
Feb 05 2015
parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thursday, February 05, 2015 12:34:34 Kagamin via Digitalmars-d wrote:
 On Thursday, 5 February 2015 at 09:43:53 UTC, Jonathan M Davis
 wrote:
 There is no such difference in the current implementation.
 assertions inside
 of in and out blocks are no different from assertions inside of
 the
 functions themselves with regards to when they are compiled in
 or not.
Good point. One problem is that base asserts throw exceptions on loosening contract on overriding method. Asserts in contracts can behave differently, e.g. derived contract can call base contract with a parameter asking to not throw on failure.
Virtual functions is the _one_ place where using in and out blocks actually makes a difference, and at the moment, it's the only reason that it makes sense for them to exist in the language IMHO - though that definitely changes if we're able to make it so that whether the contracts are run is determined by the caller rather than whoever compiled the function itself. - Jonathan M Davis
Feb 05 2015
prev sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Jonathan M Davis via Digitalmars-d"  wrote in message 
news:mailman.6014.1423124756.9932.digitalmars-d puremagic.com...

 So, if we can change the semantics of in and out blocks so that they 
 provide
 actual value, then there's definitely value in using them. But until then,
 as far as I'm concerned, they're just cruft that should be avoided.
Yes, and we are almost certainly going to change it so that the caller's flags determine if contracts are executed, not the callee's. That alone is enough to make explicit contract blocks worthwhile.
 Having some sort of compile time checking of contracts would potentally be 
 a
 case where in blocks would be of value, though I really don't see much
 difference between checking the assertions in an in block and checking any
 other assertions at compile time that can be checked at compile time -
 especially if they're at the beginning of a function.
IMO they have a different meaning either way. void func(int x) in { assert(x > 6); // If this assert fails the caller was incorrect } body { assert(x > 7); // If this assert fails then 'func' has a bug. } While these look similar, they vary in where they assign blame. It would not be valid for the compiler to give an error at the caller if the second assert is known to fail, because it's not the caller's fault. It's not uncommon to stub out unimplemented functions with assert(0), and this is not an error for the caller either. Without 'in' blocks we lose this distinction.
 The real killer feature would be if we could figure out how to make it so
 that contracts are controlled by the call site instead of being compiled 
 out
 when the function itself is compiled without assertions enabled. But I 
 have
 no idea how we could do that given that we can have function prototypes
 without the actual source code being visible at the call site.
It's possible, it's just not easy. Contracts would not be called if the prototype didn't have them, so di files would likely have the contracts retained.
Feb 05 2015
parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thursday, February 05, 2015 21:01:19 Daniel Murphy via Digitalmars-d wrote:
 "Jonathan M Davis via Digitalmars-d"  wrote in message
 news:mailman.6014.1423124756.9932.digitalmars-d puremagic.com...
 The real killer feature would be if we could figure out how to make it so
 that contracts are controlled by the call site instead of being compiled
 out
 when the function itself is compiled without assertions enabled. But I
 have
 no idea how we could do that given that we can have function prototypes
 without the actual source code being visible at the call site.
It's possible, it's just not easy. Contracts would not be called if the prototype didn't have them, so di files would likely have the contracts retained.
Well, if we can change it so that whether the contracts are run or not is determined by the caller and not the callee, then using them would definitely be worth it. But as long as that's not the case, it's not at all worth the visual noise IMHO to use in and out blocks IMHO. And if/once we change it so that whether the in and out blocks are run is determined by the caller, the visual noise will still be annoying enough to make it so that I won't be in a hurry to add them unless they're adding real value rather than just some additional, nice-to-have checks. - Jonathan M Davis
Feb 05 2015
parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Jonathan M Davis via Digitalmars-d"  wrote in message 
news:mailman.6026.1423131941.9932.digitalmars-d puremagic.com...

 Well, if we can change it so that whether the contracts are run or not is
 determined by the caller and not the callee, then using them would
 definitely be worth it. But as long as that's not the case, it's not at 
 all
 worth the visual noise IMHO to use in and out blocks IMHO. And if/once we
 change it so that whether the in and out blocks are run is determined by 
 the
 caller, the visual noise will still be annoying enough to make it so that 
 I
 won't be in a hurry to add them unless they're adding real value rather 
 than
 just some additional, nice-to-have checks.
I agree, and that's a big part of why I opened that pull request. The idea of contracts is nice but we need some real tangible benefits from them to encourage their use.
Feb 05 2015
prev sibling parent "Atila Neves" <atila.neves gmail.com> writes:
On Thursday, 5 February 2015 at 05:42:59 UTC, Meta wrote:
 On Thursday, 5 February 2015 at 01:33:54 UTC, Andrei 
 Alexandrescu wrote:
 On 2/4/15 5:32 PM, deadalnix wrote:
 On Thursday, 5 February 2015 at 01:07:56 UTC, Andrei 
 Alexandrescu wrote:
 Yah, I agree "in" is useful for overridable functions. In 
 fact I'd say
 it's useful _only_ for overridable functions.
Putting the contract in the caller is not only useful for overridable functions. 1/ If a lib is compiled in without contract, but your code is compiled with, you get the in contract to run when you call library code, but not the assert within the function. 2/ The optimizer see the properties of the argument when they get to the in contract. This information is lost in the callee, unless inlining goes on. that means the amount of contract the optimizer can remove statically is greater with in contract.
Yah, I understand the potential there. Consider me grudgingly convinced :o). -- Andrei
I don't know about others (besides Beatophile, who religiously adheres to writing contacts), but putting contracts on functions is a hassle. I never do it unless I'm feeling particularly full of divine fervor. It's a lot like making all variables that don't need to be changed immutable (another thing which only Bearophile seems to do) or properly documenting code. Strong optimization guarantees from contracts would go a long way in convincing people to actually write them (although I guess that's not what you want; Perhaps you changed your mind). It's a chicken and egg problem.
I also make all my variables immutable unless I can't. Which is annoyingly and surprisingly often. Sometimes I have to downgrade to const (usually because of strings), sometimes I have to rather sadly go back to auto. I never like it when I do. I should probably do more contract programming. immutable is good. immutable is your friend. AFAIC, mutable state is the root of all evil. Atila
Feb 05 2015
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/4/2015 5:32 PM, deadalnix wrote:
 On Thursday, 5 February 2015 at 01:07:56 UTC, Andrei Alexandrescu wrote:
 Yah, I agree "in" is useful for overridable functions. In fact I'd say it's
 useful _only_ for overridable functions.
Putting the contract in the caller is not only useful for overridable functions. 1/ If a lib is compiled in without contract, but your code is compiled with, you get the in contract to run when you call library code, but not the assert within the function. 2/ The optimizer see the properties of the argument when they get to the in contract. This information is lost in the callee, unless inlining goes on. that means the amount of contract the optimizer can remove statically is greater with in contract.
I was prepared to argue with you, but you're right on all points. Nicely done. Thanks!
Feb 05 2015
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 5 February 2015 at 01:07:56 UTC, Andrei Alexandrescu 
wrote:
 Would introduce an exception to our brace-on-its-line rule.
Will I start the next world war if I mention this rule is only useful to eat vertical space on my screen (especially when using contracts) ?
Feb 04 2015
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Feb 05, 2015 at 01:34:47AM +0000, deadalnix via Digitalmars-d wrote:
 On Thursday, 5 February 2015 at 01:07:56 UTC, Andrei Alexandrescu wrote:
Would introduce an exception to our brace-on-its-line rule.
Which is already blatantly violated everywhere in single-line functions.
 Will I start the next world war if I mention this rule is only useful
 to eat vertical space on my screen (especially when using contracts) ?
It's an example of blindly adhering to the letter of the rule while violating the spirit of the rule, which is to make code more readable. T -- Change is inevitable, except from a vending machine.
Feb 04 2015
next sibling parent reply "Jonathan Marler" <johnnymarler gmail.com> writes:
On Thursday, 5 February 2015 at 01:53:17 UTC, H. S. Teoh wrote:
 It's an example of blindly adhering to the letter of the rule 
 while
 violating the spirit of the rule, which is to make code more 
 readable.


 T
Ahhh...thanks for this. I've been searching for an eloquent way to say this for a while :)
Feb 04 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/4/15 6:10 PM, Jonathan Marler wrote:
 On Thursday, 5 February 2015 at 01:53:17 UTC, H. S. Teoh wrote:
 It's an example of blindly adhering to the letter of the rule while
 violating the spirit of the rule, which is to make code more readable.


 T
Ahhh...thanks for this. I've been searching for an eloquent way to say this for a while :)
Hey, I've been saying that all over https://issues.dlang.org/show_bug.cgi?id=14125 :o). -- Andrei
Feb 04 2015
prev sibling parent Nick Treleaven <ntrel-pub mybtinternet.com> writes:
On 05/02/2015 01:50, H. S. Teoh via Digitalmars-d wrote:
 On Thu, Feb 05, 2015 at 01:34:47AM +0000, deadalnix via Digitalmars-d wrote:
On Thursday, 5 February 2015 at 01:07:56 UTC, Andrei Alexandrescu wrote:
Would introduce an exception to our brace-on-its-line rule.
Which is already blatantly violated everywhere in single-line functions.
We really should support => syntax for these instead, they are very common. Consistent with lambdas.
Feb 05 2015
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/4/15 5:34 PM, deadalnix wrote:
 On Thursday, 5 February 2015 at 01:07:56 UTC, Andrei Alexandrescu wrote:
 Would introduce an exception to our brace-on-its-line rule.
Will I start the next world war if I mention this rule is only useful to eat vertical space on my screen (especially when using contracts) ?
As a Facebook fellow, I wouldn't mind Egyptian braces. But they won't happen. -- Andrei
Feb 04 2015
prev sibling parent reply "Kagamin" <spam here.lot> writes:
On Thursday, 5 February 2015 at 01:34:49 UTC, deadalnix wrote:
 On Thursday, 5 February 2015 at 01:07:56 UTC, Andrei 
 Alexandrescu wrote:
 Would introduce an exception to our brace-on-its-line rule.
Will I start the next world war if I mention this rule is only useful to eat vertical space on my screen (especially when using contracts) ?
If contracts would support single statements: auto opSlice(size_t low, size_t high) in assert(low <= high); in assert(0 == 0); out(r) assert(r.length == high - low); out(r) assert(!r.empty); { import std.range : take; return this[low .. $].take(high - low); }
Feb 05 2015
parent Nick Treleaven <ntrel-pub mybtinternet.com> writes:
On 05/02/2015 08:56, Kagamin wrote:
 On Thursday, 5 February 2015 at 01:34:49 UTC, deadalnix wrote:
 On Thursday, 5 February 2015 at 01:07:56 UTC, Andrei Alexandrescu wrote:
 Would introduce an exception to our brace-on-its-line rule.
Will I start the next world war if I mention this rule is only useful to eat vertical space on my screen (especially when using contracts) ?
If contracts would support single statements:
+1, but with the statements in the function body please: auto opSlice(size_t low, size_t high) { in assert(low <= high); in assert(0 == 0); out(r) assert(r.length == high - low); out(r) assert(!r.empty); import std.range : take; return this[low .. $].take(high - low); } I think that reads better. For ease of implementation inline contracts could be required to come before any runtime variables/code.
Feb 05 2015
prev sibling next sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Feb 04, 2015 at 04:24:14PM -0800, Andrei Alexandrescu via Digitalmars-d
wrote:
 I'm seeing another idiom that seems to become fashionable. Consider this
 excerpt from https://github.com/D-Programming-Language/phobos/blob/master/std/algorithm/iteration.d#L407:
 
             auto opSlice(size_t low, size_t high)
             in
             {
                 assert(low <= high);
             }
             body
             {
                 import std.range : take;
                 return this[low .. $].take(high - low);
             }
 
 which of course trivially boils down to:
 
             auto opSlice(size_t low, size_t high)
             {
                 assert(low <= high);
                 import std.range : take;
                 return this[low .. $].take(high - low);
             }
I disagree. Putting the assert in the contract means you're putting the onus on the *caller* to ensure parameters are sane. An assert inside the function body should not be vetting function arguments; that's the wrong use of assert. Asserts inside the function body should be checking for sanity *within* the function body. Requirements on parameter values are something that the *caller* should ensure, and therefore should be in the in-contract, so that the documentation will include it, and readers of the code will know what are the correct arguments to pass (they should not need to read the function body to know this). The fact that currently in-contracts generate the asserts in the callee rather than the caller (which is probably what led you to your conclusions) is a long-standing mis-implementation of DbC that, one could hope, will finally get fixed now that it is receiving some spotlight. In-contracts should be generated in the *caller*, so that any breach of contract will fail on the caller's side. This is a particularly major problem in shared libraries: when you ship a library, you generally compile it with -release, but since in-contracts are emitted in the callee's body, the asserts are skipped in -release mode, so the result is that there is *no* DbC in the shipped library. This alone puts a big dent in the usefulness of DbC in D, reducing it to nothing more than pretty (or, in this case, not-so-pretty!) syntax for what's otherwise nothing more than a glorified assert. T -- "I suspect the best way to deal with procrastination is to put off the procrastination itself until later. I've been meaning to try this, but haven't gotten around to it yet. " -- swr
Feb 04 2015
prev sibling next sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wednesday, February 04, 2015 16:24:14 Andrei Alexandrescu via Digitalmars-d
wrote:
 I'm seeing another idiom that seems to become fashionable. Consider this
 excerpt from
 https://github.com/D-Programming-Language/phobos/blob/master/std/algorithm/iteration.d#L407:

              auto opSlice(size_t low, size_t high)
              in
              {
                  assert(low <= high);
              }
              body
              {
                  import std.range : take;
                  return this[low .. $].take(high - low);
              }

 which of course trivially boils down to:

              auto opSlice(size_t low, size_t high)
              {
                  assert(low <= high);
                  import std.range : take;
                  return this[low .. $].take(high - low);
              }

 What advantage could possibly be in transforming a 5-liner into a
 9-liner? Are we really aiming at writing the maximum possible lines of
 code here and using as many language features as possible everywhere?

 I think we should dust off that Phobos contributors' guide. Sadly, there
 is little we can do against the more subtle issues.
As far as I can tell, there is zero reason to use in blocks aside from with classes, since with virtual functions, inheritance comes into play, and the semantics aren't the same. But for the vast majority of functions, I totally agree that using an in block is just visual noise. Similarly, I think that out blocks are pretty useless. They're of some value when you have multiple return statements and want to check something when the function exits, but in the vast majority of cases, what you're testing with an out contract is what unit tests would be testing, in which case, the out blocks don't really add anything, and since they're forced to be general, you can't test for specific results like you can with a unit test. Sometimes, testing something in the out block can be useful, but in my experience, unit tests almost always take care of it. So, in most cases, out contract blocks don't really add anything IMHO and are pretty pointless (though the exception of virtual functions applies in this case as well). So, while I totally agree that contract programming is valuable, I don't think that the special syntax that D provides for it is of much value except in the case of virtual functions. And the fact that that syntax is so noisy (especially when there's only one assertion) makes it kind of ridiculous IMHO to use in blocks or out blocks on non-virtual functions. - Jonathan M Davis
Feb 05 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 5 February 2015 at 08:01:06 UTC, Jonathan M Davis 
wrote:
 the function exits, but in the vast majority of cases, what 
 you're testing
 with an out contract is what unit tests would be testing, in 
 which case, the
 out blocks don't really add anything, and since they're forced 
 to be
 general, you can't test for specific results like you can with 
 a unit test.
That would be true if: - the unit test was doing exhaustive testing - the unit test is fully specified - the unit test is proven correct But post conditions that are part of a specification can in theory be used for optimization when you link object files from different sources. So you can change the implementation of one object file with only linking as long as the specification itself does not change. Well, if you had a separate specification...
Feb 05 2015
parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thursday, February 05, 2015 08:13:31 via Digitalmars-d wrote:
 On Thursday, 5 February 2015 at 08:01:06 UTC, Jonathan M Davis
 wrote:
 the function exits, but in the vast majority of cases, what
 you're testing
 with an out contract is what unit tests would be testing, in
 which case, the
 out blocks don't really add anything, and since they're forced
 to be
 general, you can't test for specific results like you can with
 a unit test.
That would be true if: - the unit test was doing exhaustive testing - the unit test is fully specified - the unit test is proven correct
If you're not doing exhaustive unit testing, you're almost certainly doing it wrong. And what you _can_ test when a function is exiting without knowing exactly what the input was and what the corresponding output is supposed to be is so minimal to be borderline useless. For something like sort, you can check that the range is sorted on exit (though that's so expensive to check that it's kind of ridiculous to check it on every call), but for most functions - even basic functions - you can't check anything. Even something like sqrt can't be checked, because you'd need to know what the input was, which out blocks don't have access to (and really can't have access to in the general case - e.g. an input range can't be saved, and it would be mutated as part of the function's operations). And even if you did have the input, to check whether the output was correct, you'd have to have some sort of simple test based solely on the input that told you whether the input was correct, and in many cases, that would basically mean reimplementing the function. In my experience, unit tests are far more valuable than any assertions inside of a function could be for verifying that a function's output is correct.
 But post conditions that are part of a specification can in
 theory be used for optimization when you link object files from
 different sources. So you can change the implementation of one
 object file with only linking as long as the specification itself
 does not change. Well, if you had a separate specification...
Right there. That's the problem. People keep coming up with ideas about how in blocks and out blocks could _theoretically_ be useful. But as it stands, there's nothing special about them at all, and the fact that D can use separate compilation tends to kill most suggestions of actually doing anything special with them. So, as it stands, in and out blocks do _nothing_ special outside of virtual functions, and they're very noisy visually, making them a huge detractor. So, personally, I don't think that they should be used outside of virtual functions. All of the supposed benefits are theoretical and don't seem likely at all to materialize any time soon - if ever. - Jonathan M Davis
Feb 05 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 5 February 2015 at 08:37:07 UTC, Jonathan M Davis 
wrote:
 If you're not doing exhaustive unit testing, you're almost 
 certainly doing
 it wrong.
That would be a NP-Hard problem for any function that takes an array as input? :-)
 And what you _can_ test when a function is exiting without 
 knowing
 exactly what the input was and what the corresponding output is 
 supposed to
 be is so minimal to be borderline useless.
You know what the input is, that is the point of a postcondition. IF and ONLY IF the precondition holds, then the postcondition holds. Without a postcondition, the precondition is meaningless.
 Even something
 like sqrt can't be checked, because you'd need to know what the 
 input was
Sure you know. And it is cheap to test too if you have "precondition(isreal(input))" then you get a fully specified "postcondition(output*output==input)". Keep in mind that contracts are for checking interoperability between cohesive units/modules/components. If you have a subcontractor that delivers a probe with a driver then you might want the precondition to be that given input (true,false) you get output in the range <0.0,1.0]. The subcontractor who writes the analytical component will have to make the analyser work for all inputs from the probe in the range <0.0,1.0]. When you scale up then the problem is that people make assumptions about how things work, which they have not implemented themselves. So testing interaction between components may be useful even after deployment. Especially if involves plugins, dynamic loading of code, hardware that is replaced...
 which out blocks don't have access to (and really can't have 
 access to in
 the general case - e.g. an input range can't be saved, and it 
 would be
 mutated as part of the function's operations).
That's a D flaw. Not a flaw with pre/postconditions and contracts.
 And even if you did have the
 input, to check whether the output was correct, you'd have to 
 have some sort
 of simple test based solely on the input that told you whether 
 the input was
 correct, and in many cases, that would basically mean 
 reimplementing the
 function.
No, the interface contract is part of the specification. The implementor has to make an implementation that makes the interface contract checkable if that is part of the deal. Anything less would be a legal contract violation. But the interface contract could be as simple as stating that the input is always in a given range. Then the implementor will only have to check for errors in that range and handle "exceptional situations" that arise within that range in a graceful manner.
 special outside of virtual functions, and they're very noisy 
 visually,
 making them a huge detractor. So, personally, I don't think
They are noisy and the language and libraries should be improved so that they can be useful for tool writers. But the language should keep the precondition and postcondition together and make them distinct from internal debugging statements. Contracts are meant to be exposed externally. That's a key point that makes them different from asserts.
 be used outside of virtual functions. All of the supposed 
 benefits are
 theoretical and don't seem likely at all to materialize any 
 time soon - if ever.
It will probably materialize if the language is adopted for large scale projects... Having explicit statements for preconditions and postconditions is useful for code readability. It is just the current syntax that is annoying.
Feb 05 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 5 February 2015 at 09:09:32 UTC, Ola Fosheim Grøstad 
wrote:
 IF and ONLY IF the precondition holds, then the postcondition 
 holds.
Duh, that was wrong... It is only IF, not IFF...
Feb 05 2015
prev sibling next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Wed, 04 Feb 2015 16:24:14 -0800, Andrei Alexandrescu wrote:

 I'm seeing another idiom that seems to become fashionable. Consider this
 excerpt from
 https://github.com/D-Programming-Language/phobos/blob/master/std/
algorithm/iteration.d#L407:
=20
              auto opSlice(size_t low, size_t high)
              in {
                  assert(low <=3D high);
              }
              body {
                  import std.range : take;
                  return this[low .. $].take(high - low);
              }
=20
 which of course trivially boils down to:
=20
              auto opSlice(size_t low, size_t high)
              {
                  assert(low <=3D high);
                  import std.range : take;
                  return this[low .. $].take(high - low);
              }
=20
 What advantage could possibly be in transforming a 5-liner into a
 9-liner? Are we really aiming at writing the maximum possible lines of
 code here and using as many language features as possible everywhere?
=20
 I think we should dust off that Phobos contributors' guide. Sadly, there
 is little we can do against the more subtle issues.
so you basically telling that "in block" feature is so useless, that even=20 language devs recommend to avoid it. great.=
Feb 05 2015
prev sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Thursday, 5 February 2015 at 00:24:15 UTC, Andrei Alexandrescu 
wrote:
 I'm seeing another idiom that seems to become fashionable. 
 Consider this excerpt from 
 https://github.com/D-Programming-Language/phobos/blob/master/std/algorithm/iteration.d#L407:

             auto opSlice(size_t low, size_t high)
             in
             {
                 assert(low <= high);
             }
             body
             {
                 import std.range : take;
                 return this[low .. $].take(high - low);
             }

 which of course trivially boils down to:

             auto opSlice(size_t low, size_t high)
             {
                 assert(low <= high);
                 import std.range : take;
                 return this[low .. $].take(high - low);
             }

 What advantage could possibly be in transforming a 5-liner into 
 a 9-liner? Are we really aiming at writing the maximum possible 
 lines of code here and using as many language features as 
 possible everywhere?

 I think we should dust off that Phobos contributors' guide. 
 Sadly, there is little we can do against the more subtle issues.


 Andrei
[caveat: I've read some of the posts, yet I don't know, if this has been proposed before in any form] What about moving the contracts somewhere else, like the unittests? auto opSlice(size_t low, size_t high) { import std.range : take; return this[low .. $].take(high - low); } contract { opSlice(size_t low, size_t high) { assert(low <= high); }; sayHello(string str) { assert(str.length); } // ... } Maybe contract functions could be labelled. contract auto opSlice(...) ... Destroy.
Feb 06 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Fri, 06 Feb 2015 14:04:39 +0000, Chris wrote:

 auto opSlice(size_t low, size_t high)
...
=20
 contract {
    opSlice(size_t low, size_t high) {
dead before the start.=
Feb 06 2015
parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 6 February 2015 at 14:29:16 UTC, ketmar wrote:
 On Fri, 06 Feb 2015 14:04:39 +0000, Chris wrote:

 auto opSlice(size_t low, size_t high)
...
 
 contract {
    opSlice(size_t low, size_t high) {
dead before the start.
Why? Would you mind to elaborate on that a little? ;)
Feb 06 2015
next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Fri, 06 Feb 2015 15:08:55 +0000, Chris wrote:

 On Friday, 6 February 2015 at 14:29:16 UTC, ketmar wrote:
 On Fri, 06 Feb 2015 14:04:39 +0000, Chris wrote:

 auto opSlice(size_t low, size_t high)
...
=20
 contract {
    opSlice(size_t low, size_t high) {
dead before the start.
=20 Why? Would you mind to elaborate on that a little? ;)
double declaration is both error-prone and not in D "spirit" ('cause it's=20 error-prone ;-). it also adds alot of noise (imagine template declaration=20 with complex constraints).=
Feb 06 2015
prev sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Fri, 06 Feb 2015 15:08:55 +0000, Chris wrote:

 On Friday, 6 February 2015 at 14:29:16 UTC, ketmar wrote:
 On Fri, 06 Feb 2015 14:04:39 +0000, Chris wrote:

 auto opSlice(size_t low, size_t high)
...
=20
 contract {
    opSlice(size_t low, size_t high) {
dead before the start.
=20 Why? Would you mind to elaborate on that a little? ;)
p.s. and people will avoid using features that involves heavily copy- pasting, and has no error protection (imagine overloaded functions). so=20 in this form it will be the feature that people will mark as "existent",=20 but will not use, 'cause it's not comfortable enough.=
Feb 06 2015
parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 6 February 2015 at 15:43:42 UTC, ketmar wrote:
 On Fri, 06 Feb 2015 15:08:55 +0000, Chris wrote:

 On Friday, 6 February 2015 at 14:29:16 UTC, ketmar wrote:
 On Fri, 06 Feb 2015 14:04:39 +0000, Chris wrote:

 auto opSlice(size_t low, size_t high)
...
 
 contract {
    opSlice(size_t low, size_t high) {
dead before the start.
Why? Would you mind to elaborate on that a little? ;)
p.s. and people will avoid using features that involves heavily copy- pasting, and has no error protection (imagine overloaded functions). so in this form it will be the feature that people will mark as "existent", but will not use, 'cause it's not comfortable enough.
Hm. But the compiler can check, if the signature is ok. E.g. contract auto opSlice(size_t low, size_t high) { return bla; } contract { opSlice(size_t low, size_t high) { assert(low < high); } opSlice(int low, int high) { // <--- Error } } or contract { auto opSlice(size_t low, size_t high) { // Implementation } // contract assert (low < high); } Dunno. I like it, if things can be put aside in blocks, like unittest or debug.
Feb 06 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Fri, 06 Feb 2015 15:59:04 +0000, Chris wrote:

 Hm. But the compiler can check, if the signature is ok. E.g.
"wtf, compiler, are you making fun of me? you KNOW what i mean, yet you=20 insisting that i have to please you... ah, fsck it! that shitty feature=20 never worth it anyway." auto foo (int n) { ... } auto foo (int n, int m) { ... } // i'm soooo sleepy contract { auto foo (int n) { ... } auto foo (int n, int m) { ...check for foo(n) that i copipasted here ...and completely forgot about it, 'cause ...that "contract" clause is sooooo far away ...from the function itself... } } and so on.
 I like it, if things can be put aside in blocks, like=20
 unittest or debug.
unittest and debug blocks are not parts of function contract, that's why=20 they can be separated. they are merely *checks*, not *prerequisites*.=
Feb 06 2015
parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 6 February 2015 at 16:22:00 UTC, ketmar wrote:
 On Fri, 06 Feb 2015 15:59:04 +0000, Chris wrote:

 Hm. But the compiler can check, if the signature is ok. E.g.
"wtf, compiler, are you making fun of me? you KNOW what i mean, yet you insisting that i have to please you... ah, fsck it! that shitty feature never worth it anyway." auto foo (int n) { ... } auto foo (int n, int m) { ... } // i'm soooo sleepy contract { auto foo (int n) { ... } auto foo (int n, int m) { ...check for foo(n) that i copipasted here ...and completely forgot about it, 'cause ...that "contract" clause is sooooo far away ...from the function itself... } } and so on.
 I like it, if things can be put aside in blocks, like unittest 
 or debug.
unittest and debug blocks are not parts of function contract, that's why they can be separated. they are merely *checks*, not *prerequisites*.
I would like to try, if it is really so bad. If laziness is an argument against it, it also applies to in {} and out {}, doesn't it?
Feb 06 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Fri, 06 Feb 2015 19:09:47 +0000, Chris wrote:

 I would like to try, if it is really so bad. If laziness is an argument
 against it, it also applies to in {} and out {}, doesn't it?
it's not lazyness per se, it's inconsistency and lack of usability. sure,=20 you are free to try, but i bet that you simply waste some time with it. i=20 have nothing personal against this (i simply don't care).=
Feb 06 2015