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

[MysticZach via Digitalmars-d]

On Thursday, 22 June 2017 at 00:27:38 UTC, Timon Gehr wrote:
> On 21.06.2017 19:39, MysticZach wrote:
>> 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.

Well I never experienced the dissonance myself, and was surprised 
to find that others did experience it. I just thought my proposal 
was a better syntax for `in` and `out` contracts.

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

It's really not clear what he meant. I guessed that the highest 
probability of what he meant was that he actually liked the DIP, 
as opposed to the mere fact that it _was_ a DIP. But as I already 
said, I could have misinterpreted his comment. In the face of 
lack of knowledge, it's a sign of wisdom to admit that one might 
be wrong, I think.

>>>> If such an alternative checking system is utilized,
>>>
>>> there should be a way to hook into the checking logic.
>>> 
>> 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 goal of this DIP, and the problem I'm trying to solve, is 
"Improve Contract Usability." And for this, H.S. Teoh's proposal 
is a very good one. But it still has a sticking point, which I 
want to resolve, namely that it elevates the existing `assert` 
functionality beyond the current requirement that one must 
explicitly write `assert`, going so far as to imply it in the 
grammar itself. But because of many complaints about the 
limitations of the assert mechanism as it currently exists, I 
would hesitate to install it into the grammar as the "One Chosen 
Way" to bail out of contracts with the new syntax.

However, if the functioning of the `assert` mechanism were more 
customizable, then it would be easier to entrust it, in my 
opinion, with the "sacred responsibility" of being installed into 
the grammar. H.S. Teoh's proposal would then stand on a firmer 
foundation, and my initial proposed syntax would become the 
inferior optionl. At that point, this DIP could be rewritten to 
advocate his syntax instead. (I think it would be better to just 
retain the number and title "DIP1009: Improve Contract Usability" 
than to make a new one for the same issue. Other DIPs have 
followed this pattern, where it was the goal and title that 
remained the same, while the specifics changed.)

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

The intent of my proposal was to make a small improvement. The 
cost (or so I thought, and may still believe) was also small. 
Small improvements are still improvements. DIP1003 is an example 
of this.

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md

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

I'm still wondering what, in practice, the difference really is. 
With existing syntax:

int fun(int a)
in { assert(a); } // 1
do {
     assert(a); // 2
     ...
}

What will the compiler or programmer actually learn from 1 if it 
violates that they won't learn from 2 if it violates? What is the 
practical incentive for `in` contracts at all? All my new syntax 
does is assume that there is in fact a difference between 1 and 
2, and makes 1 easier to write, as:

int fun(int a) {
     in assert(a); // 1
     assert(a); // 2
     ...
}

As far as syntax subtrees not belonging to their parent, I can 
see where the cognitive dissonance comes from. But it just 
doesn't seem that bad to me, since contracts are always executed 
as if they are sequential statements anyway. I would imagine that 
new programmers who only ever encountered the new proposed syntax 
would be surprised that the old syntax ever existed in the first 
place, as it's so unnecessarily awkward.

But at this point, we might as well wait for more feedback from 
other people.