DIP 1003 Formal Review

[Jonathan M Davis via Digitalmars-d]

On Sunday, May 14, 2017 08:39:12 Walter Bright via Digitalmars-d wrote:
> On 5/12/2017 9:17 AM, Mike Parker wrote:
> > The first stage of the formal review for DIP 1003 [1], "Remove body as a
> > Keyword", is now underway.
>
> A combination of Options 1 and 2:
>
> 1. Introduce 'function' as an alternative to 'body'.
> 2. Turn 'body' into a contextual keyword.
> 3. Deprecate 'body' as a contextual keyword.
> 4. Eventually remove 'body' as a contextual keyword.
>
> The advantages of this are:
>
> 1. 'body' can immediately be used as a regular identifier.
> 2. Existing code is not immediately broken.
> 3. Can have a decent deprecation period for users using 'body'.
> 4. No long term problems with contextual keywords.

Why would we want to introduce function as an alternative to body?
Personally, I've always found the need to use body to be very odd and
annoying. It doesn't need to be there when you don't have in or out
contracts, and it just makes contracts that much more verbose. It's not even
like you can put in our out contracts after the function body, so body is
needed to indicate which block the function body is - the contracts have to
go first. So, as far as I can tell, body serves no useful function. It just
makes the code longer, and the amount of extra code required around in/out
contracts is part of why I almost never use them. In most cases, it just
makes more sense to put the assertions in the function body and not have all
of that extra plumbing right after the function signature.

So, while I do like the idea of getting the word body back as an identifier,
what really appeals to me here is getting rid of the need for it with
contracts. And using function instead of body doesn't help that at all.

If we need a keyword there, then I agree that function is a good fit, but I
don't understand why having a keyword there is even beneficial. As far as I
can tell, it doesn't solve any ambiguity; it's inconsistent with function
declarations that don't have contracts; and it's just making an already
annoyingly verbose construct that much more verbose.

I like the idea of doing the deprecation in a way that avoids having
contextual keywords in the long run, and having the ability to use body as
identifier immediately would be nice - so in that sense, your proposal seems
good - but I'd _really_ like to see it be the case ultimately that no
keyword is needed for function bodies even when in/out contracts are used.

- Jonathan M Davis