On Wednesday, 21 June 2017 at 16:52:24 UTC, MysticZach wrote:
Well I'd be just as happy expanding the design limits of the
language, i.e. `assert`, if that were a better option. The
issue you raise is just how different are `in` and `out`
contracts from regular `assert` contracts.
Well, a contract is an abstraction, asserts are just one possible
implementation; so yeah, they are different things.
Technically in the current (verbose) syntax, the `assert` just
happen to be part of the contract's implementation; it could
really be just anything, including `in { if (!cond) throw
Exception }`.
They _are_ all listed in the same section of the documentation
[1], for whatever that's worth.
Well, yeah, because assert's are the most common contract
implementation in D.
The practical question is whether one can assume that the same
semantics used for `assert`, whatever they may be, will in all
cases be desirable for `in` and `out` too. The flexibility of
decoupling them is one solution, if they are clearly
sufficiently different.
They are (see abstraction vs implementation argument above). We
can just as well use another implementation in the new syntax and
then we don't have to worry about asserts semantics possibly
changing in the future anymore. Also, people arguing for changes
in assert semantics don't have to care about contracts if they
don't also do DbC. I think decoupling is the way to go here.
But another option is simply to upgrade `assert` to make sure
it offers what everyone wants.
That would be really cool, but I doubt it will be feasible here.
I think that in this case it will more likely end up with
everyone hating that universal solution equally.
I don't know what to suggest, because I don't if `assert` can
be made good enough to warrant direct inclusion into the
grammar. If it could, then all contracts, including plain
`assert` statements, would benefit from them.
Well, for me it would be this:
- The compact syntax with `in (cond)` and `out (ident)(cond)`
- Don't lower those contracts directly to any fixed
implementation; lower them to a template (similar to what I
posted) that you stick in druntime instead
- Allow configuring the template's checking semantics via D
versions (you can still then have one implementation choice in
the template be asserts, if you want, though I would go with a
more riguruous kill switch such as the one I posted)
I would definitely be interested in helping out with the template
implementation for druntime, btw.
