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

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.

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

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.

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.

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.

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

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

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

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