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