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