DIP 1003 Formal Review

Mike Parker via Digitalmars-d digitalmars-d at puremagic.com
Wed May 17 01:03:13 PDT 2017


On Wednesday, 17 May 2017 at 01:01:29 UTC, MysticZach wrote:

>
> I think there are several issues at hand, and they need to be 
> dealt with individually:
>
> 1. `body` is a very useful identifier. It would be nice to have 
> it available.
>
> 2. Contract syntax is too verbose.
>
> 3. a. Some people think code looks better with a keyword, e.g. 
> `body`, `do`, etc. distinguishing the function from the 
> contracts.
>
> 3. b. Other people think that such a keyword is unnecessarily 
> redundant and does not justify its own existence.
>
> I think the thread will be more productive if the posters 
> commit to answering just one of these issues, and reserve other 
> issues for other threads. As the DIP in question is directly 
> meant to address issue #1, it makes sense to try to solve that 
> problem and only that problem here.

Let me interject here that the primary issue we should be focused 
on in this thread is whether or not the status of `body` as a 
reserved keyword can be revoked and, if so, how to best go about 
it. Debates about the verbosity of contracts are peripherally 
related (courtesy of Option 3 in the DIP), but should not be the 
primary focus of the discussion here.

I would also like to remind everyone that the preliminary review 
of this DIP happened some time ago, and that's the place where 
free-for-all discussions are appropriate. The purpose of this 
thread is not to improve or modify the DIP, but to provide Walter 
and Andrei more food for thought when they consider if and how to 
implement the DIP.

With that in mind, I ask that we try to reduce the noise a bit by 
focusing on the key points of the DIP. As I see it, these are:

* Is it a good idea to remove body's status as a reserved keyword?

* If so, which option is best?
   1) Make it contextual
   2) Replace it with another keyword (`function` was suggested in 
the DIP, `do` in this thread).
   3) A three-stage process of removal: make it optional, then 
deprecate it, then remove it completely (meaning, no keyword, 
reserved or contextual, is required for the function body in a 
contract).

If you'd like to discuss peripheral issues in depth, I ask that 
you start another thread to do so. Feel free to post a link to 
the new thread in this one.

Thanks!





More information about the Digitalmars-d mailing list