On Wednesday, 21 June 2017 at 05:19:26 UTC, H. S. Teoh wrote:
On Wed, Jun 21, 2017 at 01:06:40AM +0000, MysticZach via
Digitalmars-d wrote:
On Tuesday, 20 June 2017 at 21:04:16 UTC, Steven Schveighoffer
wrote:
> This is much much better. The verbosity of contracts isn't
> really the brace, it's the asserts.
I think it's both, and I think the brace is the only thing
that can be improved upon. How could you justify insisting
that everyone use the built-in asserts for their contracts?
[...]
Umm... I think we're not quite on the same page here. What
*else* are people supposed to use inside their contracts
besides the built-in assert??
Many people have expressed discontent with existing asserts. In
fact, they were just changed yesterday to address one of these
concerns:
https://github.com/dlang/dmd/pull/6901
I believe `assert` would have to be extremely robust to merit
being included directly into the syntax of the language. I'm not
opposed to this in principle. But I'm no expert, and not willing
to assume it's desirable. On the other hand, if `assert` were
made so perfect as to ensure that no one would prefer a different
method of bailing out of their programs, then you're right, and
the problem of contract syntax could be solved at that level
instead of the more "pedestrian" approach I'm taking.
While D currently gives you the flexibility of arbitrary code
inside a contract, a contract is not supposed to do anything
other than to verify that the caller has passed in arguments
that are valid.[1]
To me, it's still a question of whether `assert` is the only
valid way to bail out of a program. I agree that arbitrary other
code inside contracts is bad practice, and that wanting to
prohibit it makes sense.
Furthermore, contracts specify what constitutes valid input to
the function -- this serves both as documentation to would-be
callers, and also as specification to the compiler as to what
are acceptable arguments. The built-in assert mechanism serves
both purposes -- especially the second purpose because the
compiler understands it directly, as opposed to some other
user-defined mechanism that the compiler wouldn't understand.
This wouldn't change just with a syntax rewrite. If the compiler
wanted to use `assert` for optimization purposes, it could do
that just as well with any of the proposed syntaxes. People who
didn't want to use `assert` would be at a disadvantage in this
regard. But at least they would have that option.
Besides, this is a matter of semantics, whereas this DIP is
addressing the DbC syntax. If people demand an alternative to
the built-in assert, it's not hard to have the compiler lower
the syntax into some globally-defined symbol that can be
redefined by the user. Or, indeed, simply funnel the expression
into a user-defined assert alternative, e.g.:
int myFunc(Args...)(Args args)
if (args.length > 1)
in (myAssert(args[0] > 0))
{
return doStuff(args);
}
bool myAssert(T)(T t) {
// do whatever alternative assert stuff you need to do
// here
return true; // bypass the built-in assert
}
I guess the optimizer can elide the assert if it knows it's
always true. If this method was sure not to incur a performance
penalty, then it may be better than my approach.
But the semantics is a different issue than the syntax, which
is the scope of this DIP.
The scope of the DIP can change, if need be. My primary goal is
in the title, to "Improve Contract Usability". I used this title
on purpose because I didn't want to get stuck if my proposal
turned out to be worse than some other one. If adding a new
semantics is actually preferable I can rewrite the DIP (and give
you credit — or you can do it yourself, if you want). It was just
as important to me to get the ball rolling as to have my
particular suggestion accepted. I wanted to stay close to the
shore, because I thought it was a little outlandish to propose a
whole new semantics. I still think it's a little outlandish,
because I can imagine a large organization wanting to rig up its
own bailout mechanism, and the new semantics would prevent them
from doing that. But so far, the comments suggest that it's worth
it to many people.
