DIP 1009 (Add Expression-Based Contract Syntax) Accepted

[Jonathan M Davis]

On Wednesday, April 11, 2018 05:23:58 really? via Digitalmars-d-announce 
wrote:
> On Friday, 6 April 2018 at 17:36:20 UTC, H. S. Teoh wrote:
> > Yeah, I think having expression syntax will make contracts more
> > readable.  We'll just have to see.
>
> Sorry, but I fail to see how (1) is more readable than (2)
>
> (1)
> in(s.length > 0, "s must not be empty")
>
> (2)
> in { assert(s.length > 0, "s must not be empty"); }
>
>
> In (1) The assert .. is removed.
> In (1) The scope indicators {} .. are removed.
> In (1) The semicolon..is removed.
>
> Removing all these things equates to being more readable??
>
> Sure, it makes it more concise, but more readable??
>
> I assert that it does not. But now..do I use the assert keyword..
> or not? Do I end with semicolon..or not??
>
> This just removes things that are still needed elsewhere in your
> code, but now... you have to remember that sometimes you need
> those things, and sometimes you don't.
>
> Better to have consistency over conciseness
>
> so glad to hear that existing syntax will remain.
> (well, till someone decides that needs to go too)

Many have considered the verboseness of contracts to be a major reason to
avoid them. The newer syntax will help with that in the cases where all you
need is a series of assertions. However, regardless of how anyone feels
about the new syntax, there are cases where you need more than just a series
of assertions (e.g. you need to declare one or more variables to use in the
assertions). The older syntax is required for such cases, and it would make
no sense to remove it even if we didn't care about avoiding code breakage.
So, if you prefer the older syntax, then feel free to use it, even if the
newer syntax will work. You'll be stuck reading the newer syntax in the code
of anyone who prefers the newer syntax, so you can't necessarily avoid
dealing with it, but you're not going to be forced to switch to the newer
syntax if you don't want to.

Personally, I think that new syntax is very straightforward. It may take
some getting used to, but it's basically the same syntax as an assertion
except that it has a different keyword, and because it's not a statement, it
doesn't need a semicolon. It makes sense in its context, and ultimately, I
don't think that it's really going to be readability problem.

That being said, I'm probably still not going to bother with contracts
simply because I don't see any real benefit over just putting assertions
inside the function except in the cases where inheritance is involved. I
find it a lot more tolerable than the old syntax, but I still find it to be
pointless so long as contracts are the same thing as putting assertions
inside the function (except when inheritance is involved). IMHO, for
contracts to be worth much outside of the inheritance case, we'd need to do
something like make it so that contracts are compiled in based on whether
the caller used -release or not rather than whether the callee did. If that
were done, then there would be real value in using contracts, and I'd be a
lot more excited about the new syntax. As it is, it seems like a nice
improvement that's ultimately pointless.

- Jonathan M Davis