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.

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

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

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.

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.

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!

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

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

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

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.