On Thursday, 22 June 2017 at 18:57:40 UTC, MysticZach wrote:
> [snip]

I don't mind that so much, but you made a good point earlier on how out would work with it.

The whole double parentheses is a bit ugly to me. Is there any problem with
out(return > 0)
instead of
out(r) (r > 0)

Also, I can see the point of Critique 5 in the DIP for not including in/out anywhere and wanting to pin it to the top of the body. The suggestion in your post at least succeeds at that.

On 22.06.2017 22:02, jmh530 wrote:
> 
> The whole double parentheses is a bit ugly to me. Is there any problem with
> out(return > 0)

out(a => {
    void foo()out(b => a == b){ return a; }
    return foo()>0;
}());

On Thursday, 22 June 2017 at 20:19:59 UTC, Timon Gehr wrote:
> On 22.06.2017 22:02, jmh530 wrote:
>> 
>> The whole double parentheses is a bit ugly to me. Is there any problem with
>> out(return > 0)
>
> out(a => {
>     void foo()out(b => a == b){ return a; }
>     return foo()>0;
> }());

I'm confused. The compiler should know that these returns are inside lambdas. Also, foo should not return void and I'm not sure what the extra set of parentheses are for at the end.

On 22.06.2017 22:43, jmh530 wrote:
> On Thursday, 22 June 2017 at 20:19:59 UTC, Timon Gehr wrote:
>> On 22.06.2017 22:02, jmh530 wrote:
>>>
>>> The whole double parentheses is a bit ugly to me. Is there any problem with
>>> out(return > 0)
>>
>> out(a => {
>>     void foo()out(b => a == b){ return a; }
>>     return foo()>0;
>> }());
> 
> I'm confused. The compiler should know that these returns are inside lambdas.

The point is that two results are in scope, so you cannot call both of them 'return'. It's a corner case, but you asked for any problems.

> Also, foo should not return void

Oops. That's a typo. Fixed version:

out(a => {
    int foo()out(b => a == b){ return a; }
    return foo()>0;
}())

> and I'm not sure what the extra set of parentheses are for at the end.

That's calling the lambda.

Version that works today:

int bar()out(a){
    int foo()out(b){
        assert(a==b);
    }body{
        return a;
    }
    assert(foo()>0);
}body{
    return 2;
}

On Thursday, 22 June 2017 at 20:02:17 UTC, jmh530 wrote:
> On Thursday, 22 June 2017 at 18:57:40 UTC, MysticZach wrote:
>> [snip]
>
> I don't mind that so much, but you made a good point earlier on how out would work with it.
>
> The whole double parentheses is a bit ugly to me. Is there any problem with
> out(return > 0)
> instead of
> out(r) (r > 0)

The current grammar for `out` is:

OutStatement:
   out { Statement(s) }
   out ( Identifier ) { Statement(s) }

If the out contract with the new syntax had only one assertion, and that assertion were a single identifier, there would be a parsing ambiguity:

int fun(int a) {
   int nested(int b)
   out (b) // out with a single assert, or out with identifier and brackets?
   {
      assert(b); // function body, or `out` contract?
   }
   do { ... } // function body, or do-while loop?
   while (true); // only here do we finally figure it out
}

There's probably an easy way to tidy this up, but I couldn't think of one off hand, so I suggested `out ( ) ( IfCondition )` as an unambiguous alternative. It would in fact be the rare case, since most `out` contracts will just want to check the return value.

> Also, I can see the point of Critique 5 in the DIP for not including in/out anywhere and wanting to pin it to the top of the body. The suggestion in your post at least succeeds at that.

I assume you mean H.S. Teoh's suggestion? If it's as good as the others seem to think, hopefully it will succeed more than that... but preventing enhancement 5 is as simple as having the compiler issue an error if the user violates the rule that contracts must occur first and be grouped together in the body.

On Thursday, 22 June 2017 at 21:41:55 UTC, MysticZach wrote:
>> The whole double parentheses is a bit ugly to me. Is there any problem with
>> out(return > 0)
>> instead of
>> out(r) (r > 0)

I'm sorry, I didn't read closely. I think that's just asking for trouble, wanting to use `return` as an identifier. Timon found a specific reason why, but in general contextual keywords are frowned upon for precisely this type of ambiguity in the meaning of the code.

On 22.06.2017 23:51, MysticZach wrote:
> On Thursday, 22 June 2017 at 21:41:55 UTC, MysticZach wrote:
>>> The whole double parentheses is a bit ugly to me. Is there any problem with
>>> out(return > 0)
>>> instead of
>>> out(r) (r > 0)
> 
> I'm sorry, I didn't read closely. I think that's just asking for trouble, wanting to use `return` as an identifier. Timon found a specific reason why, but in general contextual keywords are frowned upon for precisely this type of ambiguity in the meaning of the code.


(It's not a contextual keyword. A contextual keyword is an identifier that is reserved in some contexts but not others.)

On Thursday, 22 June 2017 at 21:56:29 UTC, Timon Gehr wrote:
> On 22.06.2017 23:51, MysticZach wrote:
>> On Thursday, 22 June 2017 at 21:41:55 UTC, MysticZach wrote:
>>>> The whole double parentheses is a bit ugly to me. Is there any problem with
>>>> out(return > 0)
>>>> instead of
>>>> out(r) (r > 0)
>> 
>> I'm sorry, I didn't read closely. I think that's just asking for trouble, wanting to use `return` as an identifier. Timon found a specific reason why, but in general contextual keywords are frowned upon for precisely this type of ambiguity in the meaning of the code.
>
>
> (It's not a contextual keyword. A contextual keyword is an identifier that is reserved in some contexts but not others.)

I would argue that the above suggestion promotes `return` precisely that way. It's now an identifier in precisely that one context, but is reserved as a keyword in all other contexts. Not sure what to call it. But we're a little off topic, as we both agree that the above solution to the double parens isn't viable, right?

On 23.06.2017 00:12, MysticZach wrote:
> On Thursday, 22 June 2017 at 21:56:29 UTC, Timon Gehr wrote:
>> On 22.06.2017 23:51, MysticZach wrote:
>>> On Thursday, 22 June 2017 at 21:41:55 UTC, MysticZach wrote:
>>>>> The whole double parentheses is a bit ugly to me. Is there any problem with
>>>>> out(return > 0)
>>>>> instead of
>>>>> out(r) (r > 0)
>>>
>>> I'm sorry, I didn't read closely. I think that's just asking for trouble, wanting to use `return` as an identifier. Timon found a specific reason why, but in general contextual keywords are frowned upon for precisely this type of ambiguity in the meaning of the code.
>>
>>
>> (It's not a contextual keyword. A contextual keyword is an identifier that is reserved in some contexts but not others.)
> 
> I would argue that the above suggestion promotes `return` precisely that way. It's now an identifier in precisely that one context,

It's not an identifier.

> but is reserved as a keyword in all other contexts. Not sure what to call it.

It's an overloaded keyword.

> But we're a little off topic, as we both agree that the above solution to the double parens isn't viable, right?

I think it is viable in principle, but verbose and not really in line with the existing out contract syntax.

On Thursday, 22 June 2017 at 22:28:14 UTC, Timon Gehr wrote:
>
>> But we're a little off topic, as we both agree that the above solution to the double parens isn't viable, right?
>
> I think it is viable in principle, but verbose and not really in line with the existing out contract syntax.

Yeah.