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

[H. S. Teoh via Digitalmars-d]

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:
> > On 6/20/17 1:42 PM, H. S. Teoh via Digitalmars-d wrote:
> > > Here's my counter-proposal: since the sig constraint line uses
> > > parentheses (and yes, I deliberately planted a sig constraint
> > > above just to make this point), why not go for syntactical
> > > symmetry? I.e., like this:
> > > 
> > > 	int myFunc(Args...)(Args args)
> > > 	if (Args.length > 2)
> > > 	in (args[0] != 0)
> > > 	in (args[1] > 1);	// one semicolon to end them all
> > 
> > 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??

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] 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.

([1] The current implementation lets you do crazy things like modifying
global state from inside a contract, but that's not the purpose of
contracts, and I argue that such uses are abusive.  In any case, the
current syntax isn't going away, so even if people somehow come up with
a legit reason for doing such strange things, they still can.)

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
	}

But the semantics is a different issue than the syntax, which is the
scope of this DIP.


T

-- 
Never trust an operating system you don't have source for! -- Martin Schulze