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

[MysticZach via Digitalmars-d]

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.