On Saturday, November 19, 2016 21:16:15 Dicebot via Digitalmars-d-announce wrote: > DIP 1003 is merged to the queue and open for public informal > feedback. > > PR: https://github.com/dlang/DIPs/pull/48 > Initial merged document: > https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md > > If you want the change to be approved and have ideas how to > improve it to better match on > https://github.com/dlang/DIPs/blob/master/GUIDELINES.md and > existing published reviews - please submit new PR with editorial > and ping original author.
Personally, I don't care much about having body as a usable symbol. It occasionally would be useful, but I can live without it. However, I _do_ find it very annoying that it's required for the function body when you have contracts. After all, it's not required when you write the function normally. Why should it be required when you have contracts on the function? The braces after the contracts are clearly for the function body. They couldn't be for anything else. The compiler always requires that the body be last after the in and out contracts, making the body keyword totally redundant. So, I've never understood why the body keyword was required. As far as I can tell, it fixes no ambiguity. It's just extra typing, and it makes contracts that much more verbose, which makes me that much more inclined to just not bother with them and put the assertions in the function body - particularly when I'm already of the opinion that they add no value outside of inheritance, because assertions at the beginning of the function take care of in contracts, and unit tests are really what covers the out contract case anyway (particularly since it's very rare that you can have a general test for the out contract rather than testing that specific input results in specific output). That being said, I don't care about option 1. Adding a contextual keyword just to get the body keyword is not worth the tradeoff as far as I'm concerned. Option 2 is also pointless IMHO, because you _still_ have a pointless keyword sitting on the function body. All it's doing is trying to get the body keyword back for general use, which might be nice, but it seems to me that the important thing here is to get rid of the pointless and annoying keyword on the function body, and swapping one keyword for another, longer keyword is most definitely not an improvement in that regard. IMHO, option 3 is what we should have done ages ago. Even if the keyword had been something like xyzzy rather than something that a number of folks want to use for a symbol name, it still shouldn't have been there, because it adds no value and helps to make contracts even more verbose. - Jonathan M Davis
