On Fri, Jul 21, 2017 at 01:51:05PM +0000, Mike Parker via Digitalmars-d wrote:
> DIP 1009 is titled "Improve Contract Usability".
> 
> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1009.md
[...]

As far as the meat of the proposal is concerned, I like it. The syntax of the out-contract without an identifier `out(;...)` is unfortunate, but understandable because otherwise it will cause an ambiguity with the existing verbose syntax that we will continue to support.

However, I think the presentation of the DIP needs some work. For example, the rationales and lines of reasoning that eventually led to the currently proposed syntax, both from the original draft of this DIP and from the ensuing discussion in the previous review thread, ought to be included (of course, in summarized form -- no need to repeat the back-and-forth of the original discussions, but just the eventual line of thought). If possible, some of the discarded alternatives could be mentioned along with the reasons why they were eventually decided against.

In short, I feel that a more substantial discussion of how we arrived at the current form of the proposal is important so that Walter & Andrei can have the adequate context to appreciate the proposed syntax changes, and not feel like this is just one possibility out of many others that haven't been adequately considered.

Also, I think some discussion of how the new syntax will interact with the existing one is warranted: for example, recommendations as to when to use the new syntax, and when to revert to the old (if it's a one-line contract, use the new syntax; if you need to write a for-loop in your contract, the old syntax is still available, etc.). This will also help to give W&A a better idea of how this proposal will fit in with the current syntax.

And there should be at least one example of a body-less function declaration with contracts, just to see what it looks like in that case.


T

-- 
Too many people have open minds but closed eyes.

On Friday, 21 July 2017 at 19:36:08 UTC, H. S. Teoh wrote:

>
> However, I think the presentation of the DIP needs some work. For example, the rationales and lines of reasoning that eventually led to the currently proposed syntax, both from the original draft of this DIP and from the ensuing discussion in the previous review thread, ought to be included (of course, in summarized form -- no need to repeat the back-and-forth of the original discussions, but just the eventual line of thought). If possible, some of the discarded alternatives could be mentioned along with the reasons why they were eventually decided against.
>

All of the relevant information is available. The previous version of the DIP is in a link in the header (the 'Most Recent' link in the Review Count section) and links to all previous reviews can always be found in the Reviews section at the bottom. My view is that the current version of a DIP at each stage of the process should be pristine, as if it were written specifically for that stage.

The problem I have with summarizing what came before is not everyone will agree what is the most important bits to add to the summary, and its very presence will make it easy to avoid reading previous drafts in their entirety. Much better, IMO, to just include the links and let readers decide for themselves what is important.

On Friday, 21 July 2017 at 13:51:05 UTC, Mike Parker wrote:
> DIP 1009 is titled "Improve Contract Usability".
>
> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1009.md
>
> Based on feedback from the first round, this DIP has been revised to the extent that a second preliminary review round is warranted.
>
> 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 August 4 (3:59 AM GMT August 5), or when I make a post declaring it complete.
>
> At the end of Round 2, 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!

How about this in current syntax? (that's what I do)

int func(int a)
    in
    {
        assert(a >= 0);
    }
    out(result)
    {
        assert(result >= 2);
    }
body
{
    return 2 * a;
}


an improvement could be:

int func(int a)
    in assert(a >= 0);
    out(result) assert(result >= 2);
body
{
    return 2 * a;
}

just like an in-line if-else statement

On Saturday, 22 July 2017 at 03:05:55 UTC, aberba wrote:
> How about this in current syntax? (that's what I do)
>
> int func(int a)
>     in
>     {
>         assert(a >= 0);
>     }
>     out(result)
>     {
>         assert(result >= 2);
>     }
> body
> {
>     return 2 * a;
> }
>
>
> an improvement could be:
>
> int func(int a)
>     in assert(a >= 0);
>     out(result) assert(result >= 2);
> body
> {
>     return 2 * a;
> }
>
> just like an in-line if-else statement

That was actually part of my original proposal [1]. People in that discussion [2] seemed more excited about the current proposal , and they won me over to it. If the syntax doesn't assume `assert`, probably 99% of contracts will use it explicitly, so it's really making it easier by just assuming it. And being allowed to omit the word `body` (now `do`) with the new syntax is an important feature. That said, I don't think your proposal is incompatible with the current one. It just might be made unnecessary by it.

[1] https://github.com/dlang/DIPs/blob/d2dc77802c74378cf4545069eced21f85fbf893f/DIPs/DIP1009.md

[2] http://forum.dlang.org/post/gjtsfysvtyxcfcmuutez@forum.dlang.org

On Friday, 21 July 2017 at 19:36:08 UTC, H. S. Teoh wrote:
> In short, I feel that a more substantial discussion of how we arrived at the current form of the proposal is important so that Walter & Andrei can have the adequate context to appreciate the proposed syntax changes, and not feel like this is just one possibility out of many others that haven't been adequately considered.

I think we have to assume they've been reading the prior threads. If they have specific questions or concerns, then we have to hope they'll express them here, rather than just reject the proposal. I'll put you in the author line as a co-author if you want, as this _is_ essentially your proposal.

> And there should be at least one example of a body-less function declaration with contracts, just to see what it looks like in that case.

Right now, such declarations are only legal in interfaces. That might change if the implementation changes. Here's how one would look with the new syntax:

interface I {
   void fun(int a) in(a);
}

On Saturday, 22 July 2017 at 03:05:55 UTC, aberba wrote:
>
> How about this in current syntax? (that's what I do)
>
> int func(int a)
>     in
>     {
>         assert(a >= 0);
>     }
>     out(result)
>     {
>         assert(result >= 2);
>     }
> body
> {
>     return 2 * a;
> }

I can only restate my opinion against the above as "too verbose" for the common use case of simple conditions such as null pointer, range empty, etc. Until in contracts are injected at the call site, the above is essentially equivalent to this less verbose version:
---
int func(int a)
{
    assert (a >= 0); // > should be used here, though

    int result;
    scope (success) assert (result >= 2);

    return result = 2*a;
}
---

> an improvement could be:
>
> int func(int a)
>     in assert(a >= 0);
>     out(result) assert(result >= 2);
> body
> {
>     return 2 * a;
> }
>
> just like an in-line if-else statement

Summary of issues with that (that you can also find in the Round 1 discussion):
- Free semicolons within the function signature are inconsistent with the rest of D
- The `body` keyword is redundant here; imho it should also have been removed (deprecation first) from the current contract syntax instead of being replaced by `do`, because it's inconsistent with the rest of D to require a keyword to delimit the *end* of an optional element, but since those (shell) contracts are extremely verbose, anyway, it doesn't matter much
- There already is the verbose syntax to specify contracts as "shells" that are to be explicitly filled with whatever checks one needs (assert, enforce, etc.), i.e. requiring the user to couple a contract with its implementation; the new syntax allows the user to specify contracts as what they originally are (in the DbC context): abstract promises between caller and callee with the user not needing to worry about the implementation.
- Imho the reason why current contract syntax is used only by few people is its verbosity; the more succinct the new syntax, the higher chance I think it has of yielding more widespread use

On Friday, 21 July 2017 at 19:36:08 UTC, H. S. Teoh wrote:
> However, I think the presentation of the DIP needs some work. For example, the rationales and lines of reasoning that eventually led to the currently proposed syntax, both from the original draft of this DIP and from the ensuing discussion in the previous review thread, ought to be included (of course, in summarized form -- no need to repeat the back-and-forth of the original discussions, but just the eventual line of thought). If possible, some of the discarded alternatives could be mentioned along with the reasons why they were eventually decided against.

The first draft of the current proposal actually started with this approach: https://github.com/dlang/DIPs/commit/677c4e2bd5ff9b4bcbca35a28831560d5ce06f8c

Hopefully this will help:

https://github.com/dlang/DIPs/pull/88

On Friday, 21 July 2017 at 13:51:05 UTC, Mike Parker wrote:
> DIP 1009 is titled "Improve Contract Usability".
>
> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1009.md
>
> Based on feedback from the first round, this DIP has been revised to the extent that a second preliminary review round is warranted.
>
> 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 August 4 (3:59 AM GMT August 5), or when I make a post declaring it complete.
>
> At the end of Round 2, 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!

I don't like it so much but also something like this could be considered:

out!(x => x>0)
or maybe:
out!x(x > 0)

that can't collide with current syntax

Andrea

On Saturday, 22 July 2017 at 04:48:34 UTC, MysticZach wrote:
> On Friday, 21 July 2017 at 19:36:08 UTC, H. S. Teoh wrote:
>> In short, I feel that a more substantial discussion of how we arrived at the current form of the proposal is important so that Walter & Andrei can have the adequate context to appreciate the proposed syntax changes, and not feel like this is just one possibility out of many others that haven't been adequately considered.
>
> I think we have to assume they've been reading the prior threads. If they have specific questions or concerns, then we have to hope they'll express them here, rather than just reject the proposal. I'll put you in the author line as a co-author if you want, as this _is_ essentially your proposal.

I feel like making a list of alternative proposals and why they were rejected would still be a good idea, both to improve the quality of the debate in this thread (people are proposing alternative syntaxes that should be addressed in the DIP), and for posterity.

On Tuesday, 25 July 2017 at 07:48:39 UTC, Andrea Fontana wrote:
> On Friday, 21 July 2017 at 13:51:05 UTC, Mike Parker wrote:
>> DIP 1009 is titled "Improve Contract Usability".
>>
>> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1009.md
>>
>> Based on feedback from the first round, this DIP has been revised to the extent that a second preliminary review round is warranted.
>>
>> 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 August 4 (3:59 AM GMT August 5), or when I make a post declaring it complete.
>>
>> At the end of Round 2, 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!
>
> I don't like it so much but also something like this could be considered:
>
> out!(x => x>0)
> or maybe:
> out!x(x > 0)

W.r.t. `out!`: With `Identifier !` for template instantiations `Keyword !` would effectively make two things that look the same be completely different.
W.r.t. `=>`: See replies to [1]

[1] http://forum.dlang.org/post/oio796$k6e$1@digitalmars.com