On 25.06.2017 17:46, Petar Kirov [ZombineDev] wrote:
> On Sunday, 25 June 2017 at 12:10:02 UTC, Timon Gehr wrote:
>> On 25.06.2017 13:37, Andrei Alexandrescu wrote:
>>> On 6/23/17 6:52 PM, 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 )
>>>
>>> The path of least resistance is to use existing language constructs, i.e.
>>>
>>> out result => assert(result > 0)
>>>
>>>
>>> Andrei
>> This would face quite some resistance, on the following grounds:
>>
>> out(result){ assert(result > 0); } // exists
>>
>> out result => assert(result > 0) // more of the same
>>
>> out(result; result > 0) // better
> 
> out result => result > 0 // not much worse

out(result; result > 0, "worse enough")

Also, what Guillaume said.

On Sunday, 25 June 2017 at 16:50:38 UTC, Moritz Maxeiner wrote:
> [...]

Just to be clear, I think that at least for now

out(result; result > 0, "worse enough")

is the best solution, and I support it.
Everything else are just some random ideas that I'm not pushing strongly.
As expected, my proposal's grammar wasn't to well thought through and
Guillaume Boucher provided a good example for that.

> I have no stance with having to specify a result identifier, or using __result, making `result` special, *but*: Not requiring parentheses here introduces an unacceptable language inconsistency:
>
> auto x(T)(T t)
>   if (...)
>   in (...)
>   out ...
> {
>     ...
> }
>
> If you also propose to drop the parentheses for `in`, that still leaves the inconsistency with `if`, i.e. now `if` must be changed to also drop the parentheses in template constraints. That, however, leads then to an inconsistency between different uses of `if` and thus all other occurrences of `if` in the grammar must now be made to work without parenthesis. This then leads to even more inconsistencies with `for`, `while`, etc. that now also will have to be changed.

No, I'm not proposing removing parenthesis in just one case -
I agree that it would be stupidly inconsistent and there's no
point in that. I proposed this:
T sqrt(T)(T n)
if Unqual!T U: isNumeric!U || is(U == BigInt)
in n >= 0
out (result) result * result == n
{
    //Implementation
}

But as mentioned already, that has grammar ambiguities.

So what about something like this:

T sqrt(T)(T n)
where U is Unqual!T: isNumeric!U || is(U == BigInt)
require: n >= 0
ensure result: result * result == n
{
    //Implementation
}

Assuming that in this particular case there's no need for custom error
messages, which are still unsupported for template constraints presently.

(I'm aware that this has low chances in getting into the language,
I'm just interested in hearing your unbiased opinion as if it was
targeted at a hypothetical D3.)

On Sunday, 25 June 2017 at 17:59:02 UTC, Petar Kirov [ZombineDev] wrote:
> So what about something like this:
>
> T sqrt(T)(T n)
> where U is Unqual!T: isNumeric!U || is(U == BigInt)
> require: n >= 0
> ensure result: result * result == n
> {
>     //Implementation
> }
>
> Assuming that in this particular case there's no need for custom error
> messages, which are still unsupported for template constraints presently.
>
> (I'm aware that this has low chances in getting into the language,
> I'm just interested in hearing your unbiased opinion as if it was
> targeted at a hypothetical D3.)

While I have no issues with changing keywords in the function signature like that [1], removing the parenthesis delimiters makes parsing more complex (and thus slower) for both the human reader, as well as the compiler; for me personally it's the difference between looking at the signature and grasping the meaning instantly and having to verify where the template constraint actually ends.

[1] Strictly speaking require/ensure *are* the words matching the original DbC definition, after all

On Sunday, 25 June 2017 at 12:10:02 UTC, Timon Gehr wrote:
>> The path of least resistance is to use existing language constructs, i.e.
>> 
>> out result => assert(result > 0)
>> 
>> 
>> Andrei
> This would face quite some resistance, on the following grounds:
>
> out(result){ assert(result > 0); } // exists
>
> out result => assert(result > 0) // more of the same
>
> out(result; result > 0) // better

I also imagine we'll end up seeing quite a lot of:

out( ; __result > 0)

...even though `__result` is still undocumented, because it's DRY. That's actually an incentive, IMO, to go ahead and document it. It's just tighter.

On 20.06.2017 13:57, Mike Parker wrote:
> DIP 1009 is titled "Improve Contract Usability".
> 
> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1009.md
> 
> All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on July 3 (3:59 AM GMT July 4), or when I make a post declaring it complete.
> 
> At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round. Otherwise, it will be queued for the formal review and evaluation by the language authors.
> 
> Thanks in advance to all who participate.
> 
> Destroy!


The DIP is missing the corresponding syntax for invariants:

class C{
    private int x=1;
    invariant(x>0, "x must stay positive");
}

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

On Monday, 26 June 2017 at 21:06:10 UTC, Timon Gehr wrote:
> The DIP is missing the corresponding syntax for invariants:
>
> class C{
>     private int x=1;
>     invariant(x>0, "x must stay positive");
> }
>
> Implementation:
> https://github.com/dlang/dmd/compare/master...tgehr:contract-syntax

Well done. It seems to speak to the intuitive nature of the design that it's so easy to deduce how it would work in this context.

On Monday, 26 June 2017 at 21:06:10 UTC, Timon Gehr wrote:
> Implementation:
> https://github.com/dlang/dmd/compare/master...tgehr:contract-syntax

As one of the newbie D users, who just happened to look at contract programming.

The proposed syntax for me:

* Its clear to write, not too much useless syntax
* Its not overly complex
* It fits with the language
* Easy to see the logic and order
* Useful to the point that it can remove a lot of boilerplate code out of the body structure

On Friday, 23 June 2017 at 17:31:15 UTC, MysticZach wrote:
>
> 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 )

A bit late to the party, but I would recommend the following syntax:

    out (void; myTest)

for argument-less tests. A casual reader would be less likely to see this in code and think it's some sort of typo; it would be easier to google; and it would make some semantic sense (functions that don't return anything return void).

On Tuesday, 20 June 2017 at 11:57:55 UTC, Mike Parker wrote:
> DIP 1009 is titled "Improve Contract Usability".
>
> [...]

Veering a bit off topic,the compiler doesn't treat contracts any different from other code, does it? For instance, consider:

int foo()
out(result; result>0)
{
// whatever
}

int bar(int x)
in (x<0)
{
// whatever
}

int main() {
    return bar(foo());
}

I would have liked to get a *compile-time* error in case of such a trivial contract violation. Of course, I don't expect the compilier to try and prove that a contract holds (seems unrealitic and not so useful) but it would be nice if it could at least spot simple errors, like in the example above.

In a similar vein, the information conveyed in a contract can potentially be used to apply simple optimizations, at least in trivial cases.

If the contract system amounts to placing assertions at the beginning and/or end of a function, it doesn't seem so useful except for documentation and readability.

On Tuesday, 27 June 2017 at 22:45:17 UTC, Mark wrote:
> On Tuesday, 20 June 2017 at 11:57:55 UTC, Mike Parker wrote:
>> DIP 1009 is titled "Improve Contract Usability".
>>
>> [...]
>
> Veering a bit off topic,the compiler doesn't treat contracts any different from other code, does it? For instance, consider:
>
> [...]
>
> I would have liked to get a *compile-time* error [...]

Compile time contract violation checking?
While an interesting, I'm not sure the benefits would outweigh the implementation costs.

> If the contract system amounts to placing assertions at the beginning and/or end of a function, it doesn't seem so useful except for documentation and readability.

Considering that code is read a lot more than written those two are *critically* important.
What more do you expect? It could eventually be optimized to inject the in contract check at the caller's side (before entering the function), but the point of contracts is that they *aren't* violated. If they are, well, your program[1] is broken and needs to die.

[1] abstract: computational task; implementation barring safe thread/fiber killing: process