On Monday, 15 May 2017 at 02:02:42 UTC, Basile B. wrote:
> 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.

It seems to me that the compiler could detect a presence or lack of a body simply by the presence or absence of any statement after the contracts, i.e.,

interface D {
  // fun is implicitly overridable here
  int fun() {
    in assert(...);
  }
}

Also, does a final function with contracts, but no body, make any sense? What's the use case?

Even if there were some use case for it, I can think of two solutions. One is to keep and require the current syntax for an interface function without a body. This is the natural way to install contracts anyway, for a function with no body.

The other solution is to recommend the addition of an empty statement, for an empty final function, e.g.:

// final
int fun() {
  in assert(...);
  {}
}

Considering what Jonathan said about how he never uses contracts because they're so bulky, might it not be worth it to solve the interface problem in either of the above two ways?

On Tuesday, 16 May 2017 at 03:44:54 UTC, MysticZach wrote:
> It seems to me that the compiler could detect a presence or lack of a body simply by the presence or absence of any statement after the contracts, i.e.,
>
> interface D {
>   // fun is implicitly overridable here
>   int fun() {
>     in assert(...);
>   }
> }
>
> Also, does a final function with contracts, but no body, make any sense? What's the use case?
>
> Even if there were some use case for it, I can think of two solutions. One is to keep and require the current syntax for an interface function without a body. This is the natural way to install contracts anyway, for a function with no body.
>
> The other solution is to recommend the addition of an empty statement, for an empty final function, e.g.:
>
> // final
> int fun() {
>   in assert(...);
>   {}
> }
>
> Considering what Jonathan said about how he never uses contracts because they're so bulky, might it not be worth it to solve the interface problem in either of the above two ways?

I should have said *three* ways, because it's quite possible to conclude that there will never be a use case for a final function in an interface to have contracts, but no body, and therefore assume that contracts plus a lack of statements --> an overridable function.

On 16.05.2017 05:44, MysticZach wrote:
> ...

With your proposal, this syntax would already be taken for a function with an empty implementation.

> Also, does a final function with contracts, but no body, make any sense?
> What's the use case?
> ...

di files.

> Even if there were some use case for it, I can think of two solutions.
> One is to keep and require the current syntax for an interface function
> without a body. This is the natural way to install contracts anyway, for
> a function with no body.
>
> The other solution is to recommend the addition of an empty statement,
> for an empty final function, e.g.:
>
> // final
> int fun() {
>   in assert(...);
>   {}
> }
>
> Considering what Jonathan said about how he never uses contracts because
> they're so bulky, might it not be worth it to solve the interface
> problem in either of the above two ways?

No. Contracts are not part of the function body, they are part of the function signature. That's the point.

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

The purpose of the DIP is to reclaim the keyword. If you want shorter contracts, then:

int f(int a)
  in assert(a>0)
  out(r) assert(b==a+1)
{
  return a+1;
}

On Tuesday, 16 May 2017 at 10:28:09 UTC, Kagamin wrote:
> On Monday, 15 May 2017 at 01:18:02 UTC, Jonathan M Davis wrote:
>> 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.
>
> The purpose of the DIP is to reclaim the keyword. If you want shorter contracts, then:
>
> int f(int a)
>   in assert(a>0)
>   out(r) assert(b==a+1)
> {
>   return a+1;
> }

Yes, please keep the discussion focused on the the removal of `body` and how to best go about that. I do agree though that we could and should make contracts shorter. Maybe in another DIP after this one.

On Tuesday, May 16, 2017 12:50:37 Meta via Digitalmars-d wrote:
> On Tuesday, 16 May 2017 at 10:28:09 UTC, Kagamin wrote:
> > On Monday, 15 May 2017 at 01:18:02 UTC, Jonathan M Davis wrote:
> >> 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.
> >
> > The purpose of the DIP is to reclaim the keyword. If you want shorter contracts, then:
> >
> > int f(int a)
> >
> >   in assert(a>0)
> >   out(r) assert(b==a+1)
> >
> > {
> >
> >   return a+1;
> >
> > }
>
> Yes, please keep the discussion focused on the the removal of `body` and how to best go about that. I do agree though that we could and should make contracts shorter. Maybe in another DIP after this one.

All I'm arguing for is that if we're removing body as a keyword, there's no need to replace it with function or any other word in contracts. We can simply deprecate its use as a keyword and not replace it, letting it then be used as a normal identifier in whatever fashion makes the most sense. Actually changing the overall syntax of contracts is a whole other can of worms.

- Jonathan M Davis

On Tuesday, 16 May 2017 at 13:50:59 UTC, Jonathan M Davis wrote:
> All I'm arguing for is that if we're removing body as a keyword, there's no need to replace it with function or any other word in contracts. We can simply deprecate its use as a keyword and not replace it, letting it then be used as a normal identifier in whatever fashion makes the most sense.

+1, Makes total sense to me. So simple. I'm for this.

> Actually changing the overall syntax of contracts is a whole other can of worms.

Yeah. One thing at a time.

On 15.05.2017 03:18, Jonathan M Davis via Digitalmars-d wrote:
> 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.

auto foo()in{
    assert(true);
}out{
    assert(true);
}{
    return 3;
}

Are you really arguing for this?
I don't want to write code like this.

On Tuesday, May 16, 2017 17:22:12 Timon Gehr via Digitalmars-d wrote:
> On 15.05.2017 03:18, Jonathan M Davis via Digitalmars-d wrote:
> > 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.
>
> auto foo()in{
>      assert(true);
> }out{
>      assert(true);
> }{
>      return 3;
> }
>
> Are you really arguing for this?
> I don't want to write code like this.

Well, I can't say that I like the formatting, but most definietly I am arguing for that. Right now, just because you add contracts, you suddenly have to add an extra keyword that is unnecessary when there are no contracts and which is redundant. You go from having something like

auto foo(T param)
{
    ...
}

to something like

auto foo(T param)
in
{
    assert(...);
}
out(result)
{
    assert(...);
}
body
{
    ...
}

or

auto foo(T param)
in { assert(...); }
out(result) { assert(...); }
body
{
    ...
}

or however you want to format it. But the last set of braces is always the function body just like it is when there are no contracts. And having to have body (or function whatever other keyword we might put there) just makes contracts that much more verbose - as well as being inconsistent with how functions bodies are declared when there are no contracts.

Honestly, as nice as it would be to get the body keyword back as an identifier, I care _way_ more about not having a redundant keyword for the function body. I'd be all for removing it from contracts even if we never got it back as an identifier. I've always found needing to add body to be very annoying, and I frequently forget it, because it's not there normally. It's just making contracts longer without adding extra information, and contracts are _way_ too verbose even without the extra keyword there, let alone with it.

IMHO, if we remove body as a keyword but replace it with something else in contracts, we've lost out on a big opportunity for some language cleanup.

- Jonathan M Davis

On 5/12/17 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. From now until 11:59 PM ET on May 26 (3:59 AM GMT on May 27), the community has the opportunity to provide last-minute feedback. If you missed the preliminary review [2], this is your chance to provide input.
> 
> At the end of the feedback period, I will submit the DIP to Walter and Andrei for their final decision. Thanks in advance to those of you who participate.
> 
> [1] https://github.com/dlang/DIPs/blob/fbb797f61ac92300eda1d63202157cd2a30ba555/DIPs/DIP1003.md 
> 
> 
> [2] http://forum.dlang.org/thread/qgxvrbxrvkxtimzvnetu@forum.dlang.org

One possible substitute for the `function` keyword in option 2 could be `do`. I'm not convinced it's a good substitute, but I thought I'd throw it out there.