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

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) ?

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.

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

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

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

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?

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.

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

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.