Another idiom I wish were gone from phobos/druntime

[Zach the Mystic via Digitalmars-d]

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?