DIP 1009--Improve Contract Usability--Preliminary Review Round 1

[Timon Gehr via Digitalmars-d]

On 21.06.2017 19:39, MysticZach wrote:
> On Wednesday, 21 June 2017 at 15:18:21 UTC, Timon Gehr wrote:
>> On 21.06.2017 02:51, MysticZach wrote:
>>>
>>> I think people could get used to the cognitive dissonance.
>>
>> That's really not what D is about.
> 
> My counterargument to that is that it's possible that the cognitive 
> dissonance only occurs because of what people are used to, rather than 
> what is inherent to the syntax.
> ...

This is a purely philosophical distinction without empirical basis.

>>> I've already gotten used to it just by writing this DIP.
>>
>> I think it is likely that you are an outlier.
> 
> Well my impression was that Walter liked it too, although I could have 
> misinterpreted his comment here:
> 
> http://forum.dlang.org/post/ogvt66$1bcp$1@digitalmars.com
> ...

He is saying it is good that a DIP to improve contract syntax /exists/. 
I agree with that.

>>> If such an alternative checking system is utilized,
>>
>> If so, there should be a way to hook into the checking logic. This has 
>> nothing at all to do with contract syntax. asserts and contracts are 
>> coupled already, as in-contracts form a disjunction on override by 
>> catching AssertErrors.
> 
> Improving the checking logic interface may solve at a higher level the 
> problem I'm trying to solve at a very low one, with mere syntax changes, 
> and it might be (is probably?) the best way forward.
> ...

Your proposal does not solve this problem, and there is no need for this 
DIP to do that.

>>> the syntax for  writing contracts should be as easy
>>> for them as for those using `assert`.
>>
>> Maybe, but your DIP does not pull its own weight as long as the latter 
>> syntax is not a notable improvement over what we have now.
> 
> Well, my view is that my DIP is actually a very lightweight syntax 
> change, and an equally lightweight improvement in contract syntax, so 
> it's a lost-cost, mild improvement .

We are looking for a significant improvement. Otherwise, what's the 
point? We need to justify the cost.

> The cognitive dissonance argument 

(Just to be clear: I think framing it as a psychological issue does not 
have much merit.)

> is the main one against it, and I really don't know if that dissonance 
> is based on fundamental flaws in the way I'm thinking about it,

The point of contracts is assigning blame by documenting assumptions and 
guarantees. If something within the function body crashes, it's ideally 
the fault of the function implementation.

> or just the "Shock of the New" [1].

I like new as long as it is an improvement. This is not. Having syntax 
subtrees that do not actually logically belong to their parent in the 
grammar is awkward language design, especially if they affect the 
parent's signature.

> ...
> As far as Teoh's proposal, I would say that its quality is highly 
> correlated to the percentage of projects that find built-in `assert` 
> adequate to their needs,

The two issues might need to be decoupled, but that is not the job of 
the contract syntax overhaul.

> which is hard to assess precisely - the better 
> `assert` is, or can be made to be, the better Teoh's proposal is, I'd 
> say.

Projects that want to do fancy things within contracts can use the 
existing contract syntax, but all they can legitimately do is throw 
AssertErrors, possibly with a message, just as assert does; the new 
syntax does not change this fact.

(BTW: There should be an optional message, as in: in(test(), "test 
failed").)