Misleading contract syntax

[Norbert Nemec]

Ary Borenszweig wrote:
> Pelle Månsson wrote:
>> On 03/04/2010 02:24 PM, Ary Borenszweig wrote:
>>> Norbert Nemec wrote:
>>>> Hi there,
>>>>
>>>> following the recent thread on contracts, I come to the conclusion
>>>> that the current syntax is misleading and counterproductive.
>>>>
>>>> * The concept of a contract is an expression, not a statement.
>>>> * A contract should *never* have side effects, otherwise debugging
>>>> code may behave differently from release mode (which is the ultimate
>>>> nightmare).
>>>> * Any reasonable example with contracts contains just a list of
>>>> assertions.
>>>> * There is a fundamental distinction between assertions and contracts
>>>> (see recent thread: contracts are part of interface design, assertions
>>>> are computable comments)
>>>>
>>>> => Why are contracts defined as lists of statements in the first
>>>> place? Defining contracts as side-effect free expressions would solve
>>>> all of the above problems at once, decoupling the concepts of
>>>> assertions and contracts and resulting in safer, much more concise 
>>>> code.
>>>
>>> int binary_search(int[] array, int n);
>>>
>>> Write the precondition of this function using only ors and ands (and no
>>> helper functions).
>>
>> Why should you not be allowed helper functions?
> 
> Ok, but I don't want the language to force me to write helper functions 
> just to write my contracts.


Anything complex enough to need a helper function is very likely useful 
to have anyway, e.g. to allow the library user to check for the 
condition before calling the function. (Remember: the contract check is 
just a safety net. It still is the caller's responsibility to make sure 
that the input is legal before calling the function)

Apart from that: an occasional helper function causes far less clutter 
than the current syntax with all the "assert" keywords in each contract.