On Thursday, 22 June 2017 at 13:11:12 UTC, MysticZach wrote:
On Thursday, 22 June 2017 at 12:54:00 UTC, MysticZach wrote:
On Thursday, 22 June 2017 at 10:59:18 UTC, Moritz Maxeiner
wrote:
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.
Okay. Then the proposal needs to be accompanied by an explicit
description of how to hook into the new semantics. Which is
what you provided, but I suppose it would need to be exactly
specified. In particular, where exactly is the code for the
(optional) user-defined hook to be found? In a separate file,
maybe as indicated with a command line option, e.g.
`-contractsConfig=myContracts.d`?
As long as one is doing this, maybe a proposal for user-defined
`assert` should be provided too? It'd be interesting to have a
dedicated file for user-defined assert and contract
configuration. The core idea is to allow *everyone*, from large
companies to individual hobbyists, to use `assert`, `in`, and
`out`, and have it work the way they want. I would definitely
need help writing that DIP.
Upon reflection, that is exactly what my Insister proposal is :p
The reason it's not called Asserter, btw, is that assert is a
a) a keyword, and
b) is already deeply entrenched with the concept of Errors
(bugs), in D
and that `enforce`, is also de facto established for Exceptions
(user input error),
so `insist` would then be a configurable chooser between the two.
