On Friday, 23 June 2017 at 13:58:38 UTC, Moritz Maxeiner wrote:
> OT: Anyone interested in a DIP for more template constraint unfulfilled information in a consistent way to contracts (?) :
> ---
> int myFunc(Args...)(Args args)
>   if (Args.length > 0, "Starving!")
>   if (Args.length > 1, "Still hungry!")
>   if (Args.length > 2, "Just a little bit more!")
>   in (args[0] != 0, "Yikes!")
>   in (args[1] > 1, "Why you do this?")
>   out (result; result > 0, "Oops...") { ... }
> ---

This would be a good question for a different thread.

On 6/23/17 9:58 AM, Moritz Maxeiner wrote:

>    out (; globalStateStillValid) { ... }

What's that mean?

-Steve

On Friday, 23 June 2017 at 14:53:44 UTC, Steven Schveighoffer wrote:
> On 6/23/17 9:58 AM, Moritz Maxeiner wrote:
>
>>    out (; globalStateStillValid) { ... }
>
> What's that mean?

Parenthesisless function call (as function calls are expressions).

On Fri, Jun 23, 2017 at 09:06:59AM +0000, Solomon E via Digitalmars-d wrote: [...]
> T foo(T)(T x, T y)
>     in (x > 0, y > 0)
>     out (r; r > 0)
> {
>     return x % y + 1;
> }

Hmm, I like this syntax for out-contracts!  It borrows from existing foreach syntax, so it has some precedence, whereas the previous proposal of `out(...)(...)` looks uglier and also looks deceptively like a template function declaration.

`out (r; r > 0)` gets my vote.


OTOH, I don't like the comma in the in-contract.  Let's just keep it as either separate clauses:

	in (x > 0)
	in (y > 0)

or just use a boolean operator:

	in (x > 0 && y > 0)


T

-- 
Two wrongs don't make a right; but three rights do make a left...

On 6/23/17 11:41 AM, Moritz Maxeiner wrote:
> On Friday, 23 June 2017 at 14:53:44 UTC, Steven Schveighoffer wrote:
>> On 6/23/17 9:58 AM, Moritz Maxeiner wrote:
>>
>>>    out (; globalStateStillValid) { ... }
>>
>> What's that mean?
> 
> Parenthesisless function call (as function calls are expressions).

OK. so if I read that correctly, you are saying you don't need to use the result in your out contract, and the { ... } is actually the function body? I initially read the { ... } as part of the out contract.

-Steve

On Friday, 23 June 2017 at 16:21:28 UTC, H. S. Teoh wrote:
> On Fri, Jun 23, 2017 at 09:06:59AM +0000, Solomon E via Digitalmars-d wrote: [...]
>> T foo(T)(T x, T y)
>>     in (x > 0, y > 0)
>>     out (r; r > 0)
>> {
>>     return x % y + 1;
>> }
>
> Hmm, I like this syntax for out-contracts!  It borrows from existing foreach syntax, so it has some precedence, whereas the previous proposal of `out(...)(...)` looks uglier and also looks deceptively like a template function declaration.
>
> `out (r; r > 0)` gets my vote.
>
>
> OTOH, I don't like the comma in the in-contract.  Let's just keep it as either separate clauses:
>
> 	in (x > 0)
> 	in (y > 0)

Yeah, my take is that the grammar for `assert`s applies to the new syntax as well. If the grammar for asserts is this:

AssertExpression:
  assert ( AssertParameters )

... then the grammar for the new syntax is:

InExpression:
  in ( AssertParameters )

OutExpression:
  out ( ; AssertParameters )
  out ( Identifier ; AssertParameters )

On Friday, 23 June 2017 at 17:31:15 UTC, MysticZach wrote:
>
> OutExpression:
>   out ( ; AssertParameters )
>   out ( Identifier ; AssertParameters )

Why not?

OutExpression:
  out ( AssertParameters )
  out ( Identifier ; AssertParameters )

On 23.06.2017 18:21, H. S. Teoh via Digitalmars-d wrote:
> On Fri, Jun 23, 2017 at 09:06:59AM +0000, Solomon E via Digitalmars-d wrote:
> [...]
>> T foo(T)(T x, T y)
>>      in (x > 0, y > 0)
>>      out (r; r > 0)
>> {
>>      return x % y + 1;
>> }
> 
> Hmm, I like this syntax for out-contracts!  It borrows from existing
> foreach syntax, so it has some precedence, whereas the previous proposal
> of `out(...)(...)` looks uglier and also looks deceptively like a
> template function declaration.
> 
> `out (r; r > 0)` gets my vote.
> 
> 
> OTOH, I don't like the comma in the in-contract.  Let's just keep it as
> either separate clauses:
> 
> 	in (x > 0)
> 	in (y > 0)
> 
> or just use a boolean operator:
> 
> 	in (x > 0 && y > 0)
> 
> 
> T
> 

Agreed. Implementation:
https://github.com/dlang/dmd/compare/master...tgehr:contract-syntax

(At most one contract of each type is supported. It is not very hard to implement multiple contracts, but this requires touching semantic analysis.)

On 23.06.2017 19:52, jmh530 wrote:
> On Friday, 23 June 2017 at 17:31:15 UTC, MysticZach wrote:
>>
>> OutExpression:
>>   out ( ; AssertParameters )
>>   out ( Identifier ; AssertParameters )
> 
> Why not?
> 
> OutExpression:
>    out ( AssertParameters )
>    out ( Identifier ; AssertParameters )

Because it cannot be parsed greedily. See:
http://forum.dlang.org/post/beovehhmoxzuoepterzz@forum.dlang.org

On Friday, 23 June 2017 at 17:09:18 UTC, Steven Schveighoffer wrote:
> On 6/23/17 11:41 AM, Moritz Maxeiner wrote:
>> On Friday, 23 June 2017 at 14:53:44 UTC, Steven Schveighoffer wrote:
>>> On 6/23/17 9:58 AM, Moritz Maxeiner wrote:
>>>
>>>>    out (; globalStateStillValid) { ... }
>>>
>>> What's that mean?
>> 
>> Parenthesisless function call (as function calls are expressions).
>
> OK. so if I read that correctly, you are saying you don't need to use the result in your out contract, and the { ... } is actually the function body?

Yes, as was proposed here[1]

> I initially read the { ... } as part of the out contract.

The example was just meant to give an overview of all contract specification variants of the latest proposal (which I support).

[1] http://forum.dlang.org/post/wgarisncalisyleckikg@forum.dlang.org