On Friday, 12 May 2017 at 16:17:03 UTC, Mike Parker wrote:
> [1] https://github.com/dlang/DIPs/blob/fbb797f61ac92300eda1d63202157cd2a30ba555/DIPs/DIP1003.md

Currently function declarations with contracts don't require semicolon at the end. This conflicts with options 1 and 3 and is not addressed in the DIP.

On Friday, 12 May 2017 at 18:03:43 UTC, H. S. Teoh wrote:
> I disagree that `function` is not overloaded: it *will* be overloaded if option 2 is chosen, because `function` currently means function *pointer*, not the function body itself.  For this reason, I oppose Option 2.

Function literal includes function body.

On Sunday, 14 May 2017 at 16:35:32 UTC, Kagamin wrote:
> On Friday, 12 May 2017 at 16:17:03 UTC, Mike Parker wrote:
>> [1] https://github.com/dlang/DIPs/blob/fbb797f61ac92300eda1d63202157cd2a30ba555/DIPs/DIP1003.md
>
> Currently function declarations with contracts don't require semicolon at the end. This conflicts with options 1 and 3 and is not addressed in the DIP.

I'm confused as to how this conflicts with option 1. Can you explain?

On 14.05.2017 18:36, Kagamin wrote:
> On Friday, 12 May 2017 at 18:03:43 UTC, H. S. Teoh wrote:
>> I disagree that `function` is not overloaded: it *will* be overloaded
>> if option 2 is chosen, because `function` currently means function
>> *pointer*, not the function body itself.  For this reason, I oppose
>> Option 2.
>
> Function literal includes function body.

auto add = function int(int a,int b)in{
    assert(0<=a && 0 <=b && a<=int.max-b);
}body{
    return a+b;
};

On 14.05.2017 17:39, Walter Bright 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.

The drawback is that option 2 is not a good option.

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

On Monday, 15 May 2017 at 01:18:02 UTC, Jonathan M Davis wrote:
> 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.

Not that a whole new way of doing things is called for... but I think a better design would have been to allow 'in' and 'out' statements in the function itself, with no need for brackets if you only have one line's worth of contract, e.g.,

int fun(int a) {
  in assert(...);
  out(x) assert(...);

  // do stuff
}

On Monday, 15 May 2017 at 01:39:34 UTC, MysticZach wrote:
> Not that a whole new way of doing things is called for... but I think a better design would have been to allow 'in' and 'out' statements in the function itself, with no need for brackets if you only have one line's worth of contract, e.g.,
>
> int fun(int a) {
>   in assert(...);
>   out(x) assert(...);
>
>   // do stuff
> }

You could even accumulate in statement if you want to save on brackets and indentation:
int fun() {
  in assert(...);
  in assert2(...);

  // etc.
}

On Monday, 15 May 2017 at 01:39:34 UTC, MysticZach wrote:
> Not that a whole new way of doing things is called for... but I think a better design would have been to allow 'in' and 'out' statements in the function itself, with no need for brackets if you only have one line's worth of contract, e.g.,
>
> int fun(int a) {
>   in assert(...);
>   out(x) assert(...);
>
>   // do stuff
> }

It's nice, i like it but it cant work as simply. You're forgetting that interface member functions can have contracts. With this syntax interfaces member functions would always have a body BUT the current semantic is that interface member functions with bodies are final methods. Boom. Interfaces don't work anymore because there's no easy way to make the difference between an interface member function that's final and an interface member function that's not pre-implemented (so overridable) but has contracts.

On Friday, 12 May 2017 at 16:17:03 UTC, Mike Parker wrote:
> ...

3. deprecate, remove, forget.

During the deprecation period, it could live as "contextual keyword", or actually with grammar modified to expect an identifier "body" instead of keyword. That would allow using "body" as identifier immediately.