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

[Moritz Maxeiner via Digitalmars-d]

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

What happens with H.S. Teoh's proposal is not that `assert` is 
implied by the grammar, but that a function can *finally* specify 
its contracts *independent* of how those contracts are actually 
implemented. That's a good thing, because
a) it allows the contract implementation for that new syntax to 
be swapped out transparently (no changes need to be made by the 
programmer to get a better contract implementation)
b) it makes contracts more compact (and thus easier to read) 
without losing relevant information (contract implementation is 
not something you should have to deal with for every single 
library independently)

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

Again, that's not what H.S. Teoh's proposal would do. All it does 
is install an *implementation agnostic*, *abtract* way to specify 
contracts into the grammar. Whether that is lowered to assert, or 
anything else is an implementation detail and it certainly isn't 
fixed to asserts.
Simply document the behaviour one can expect when using it in 
debug and release mode and leave the implementation details 
(assert or something else) unspecified.

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

A more customizable assert would not change anything for the DIP 
imo, since I do not want implementation details to be part of 
contract writing.

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

DIP1003 did not introduce an entirely new system, it merely 
slightly changed an existing sytem.
DIP1009 *does* introduce several new syntax forms, i.e. adding a 
whole new system, which means it *also* introduces the 
responsibility of maintaining backwards compatibility when 
someone tries to improve contracts again (and then we would have 
three systems to specify contracts).
Both DIP1003 and DIP1009 need to have a positive benefit/cost 
balance, which is easy for DIP1003 (since the costs are 
insignificant), but not for DIP1009: The costs are high down the 
line and it needs to justify them. The only way I can see those 
costs being justified is by separating constract specification 
from contract implementation and that requires syntax similar to 
H.S. Teoh's proposal.