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

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.

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

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.

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

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.

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.

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

so you basically telling that "in block" feature is so useless, that even language devs recommend to avoid it. great.

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

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)
> 
> 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 shit in the language due to non-existent Jack The Random Reddit User told that he used that shit once? does that mean that typle syntax PR will be accepted, 'cause blocking it is a look at some vague possible future benefit?