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.

On 20/11/2016 10:16 AM, Dicebot 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.

I'm not keen on the replacement syntax but I love the idea.

I was thinking maybe option 3 but not have the body first.

int func(int arg) {
	return 8 * arg;
} in {
	assert(arg > 0);
} out(int value) {
	assert(1);
}

Would break code but its a simple rearrangement.

On Sun, 20 Nov 2016 14:35:16 +1300, rikki cattermole wrote:
> I was thinking maybe option 3 but not have the body first.
> 
> int func(int arg) {
> 	return 8 * arg;
> } in {
> 	assert(arg > 0);
> } out(int value) {
> 	assert(1);
> }
> 
> Would break code but its a simple rearrangement.

Right now, the normal flow when reading a function is:

* Doc comment: What did the author think important for me to know?
* Signature: How do I call it so the compiler will accept it?
* In contract: What sort of parameters are acceptable?
* Out contract: What invariants apply to the result?
* Body: I only need to read this if the rest didn't help.

This is ordered by importance.

By hanging the contracts off the end, you're making them harder to notice. That's not ideal.

On Saturday, 19 November 2016 at 21:16:15 UTC, Dicebot wrote:
> DIP 1003 is merged to the queue and open for public informal feedback.

Perhaps a good idea for D3...

Am 19.11.2016 um 22:16 schrieb Dicebot:
> 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.

I'd really like to see option 3, combined with option 1. The verbosity of the current syntax, as well as the sub-optimal contract semantics for classes*, make me personally almost always resort to normal assertions in the function body instead of using contracts.

That "body" is not available as an identifier is also quite annoying for certain applications. This is the case for a bunch of other keywords, too, but "body" as a keyword just has extremely little value, so it does stick out.

Really nice would be if "in" and "out" would then also take a general statement instead of just a block statement, so that a syntax like this would become possible for simple contracts:

    void foo(int a, int b)
      in assert(0 <= a && a < b);
      out(ret) assert(ret < b);
    {
      return b - 1 - a;
    }

The current equivalent just looks crowded and becomes hard to read, or wastes lots of vertical space if braces are put on their own line:

    void foo(int a, int b)
      in { assert(0 <= a && a < b); }
      out(ret) { assert(ret < b); }
    body {
      return b - 1 - a;
    }

For this whole proposal to work out, though, I think the old syntax will have to stay supported without deprecations, because the amount of breakage (the deprecation path won't change that) will otherwise probably be huge. Making "body" optional + contextual seems to be the way to go.

Since "body" is only used in a tiny and specific grammatical niche of the language, I also think that Walter's generic arguments form the linked thread don't really apply here, similar to "scope(...)" or "extern(...)".




* Example:

    interface Foo {
      void foo(int x) in { assert(x < 10); };
    }

    class Bar : Foo {
      // no contract enforced, because an omitted contract always
      // counts as a passing contract - need in { assert(false); } here
      override void foo(int x) { ... }
    }

On Saturday, 19 November 2016 at 21:16:15 UTC, Dicebot 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.

How about this alternative ("in" and "out" blocks inside function body):

void foo(int a)
{
	in
	{
		assert (a > 0);
	}
	out
	{
		(ret) assert(ret > 0);
	}

	// body code

	return a;
}


or for one-liners:

void foo(int a)
{
	in assert (a > 0);
	out (ret) assert(ret > 0);

	// body code

	return a;
}

BR,
Piotrek

On 21.11.2016 17:55, Piotrek wrote:
> On Saturday, 19 November 2016 at 21:16:15 UTC, Dicebot 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.
>
> How about this alternative ("in" and "out" blocks inside function body):
>
> void foo(int a)
> {
>     in
>     {
>         assert (a > 0);
>     }
>     out
>     {
>         (ret) assert(ret > 0);
>     }
>
>     // body code
>
>     return a;
> }
>
>
> or for one-liners:
>
> void foo(int a)
> {
>     in assert (a > 0);
>     out (ret) assert(ret > 0);
>
>     // body code
>
>     return a;
> }
>
> BR,
> Piotrek

Won't work. Contracts are part of the function signature. That's the point.

On 19.11.2016 22:16, Dicebot 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.

I'm opposed to both option 2 and option 3 on the basis that they are both plain ugly (also, breaking), 2 is verbose, 3 is ambiguous. (Doing nothing is much better than 2 or 3.)

For option 1, the "on the basis that they will complicate the parser" argument is weak. Just lex 'body' as an identifier and expect to see that identifier in the parser. TOKbody occurs 4 times in DMD's parser, all of them are trivial to replace.

On Monday, 21 November 2016 at 20:59:32 UTC, Timon Gehr wrote:
>> How about this alternative ("in" and "out" blocks inside function body):
>>
>> void foo(int a)
>> {
>>     in
>>     {
>>         assert (a > 0);
>>     }
>>     out
>>     {
>>         (ret) assert(ret > 0);
>>     }
>>
>>     // body code
>>
>>     return a;
>> }
>>
>>
>> or for one-liners:
>>
>> void foo(int a)
>> {
>>     in assert (a > 0);
>>     out (ret) assert(ret > 0);
>>
>>     // body code
>>
>>     return a;
>> }
>>
>> BR,
>> Piotrek
>
> Won't work. Contracts are part of the function signature. That's the point.

How does "auto" work? Can't the inner in&out be applied to the signature?

BR,
Piotrek

Am 21.11.2016 um 22:19 schrieb Timon Gehr:
> 3 is ambiguous.

Can you give an example?