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.
