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!

On Friday, 21 July 2017 at 13:51:05 UTC, Mike Parker wrote:
> DIP 1009 is titled "Improve Contract Usability".

I like it.

I would prefer the out with two sets of parantheses.

On 21.07.2017 15:51, 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!


"in and out expressions must come at the end of the function declarator suffix, and before the regular contracts, if any"

The implementation actually allows all possible notations for contracts to be mixed freely. Whether or not 'do' is required depends on what notation is used by the last contract.

On Friday, 21 July 2017 at 15:13:09 UTC, Timon Gehr wrote:
> "in and out expressions must come at the end of the function declarator suffix, and before the regular contracts, if any"
>
> The implementation actually allows all possible notations for contracts to be mixed freely. Whether or not 'do' is required depends on what notation is used by the last contract.

I decided that for grammar purposes it would be easier to require the contract expressions before the contract blocks. Contract blocks are currently conflated grammatically with FunctionBody [1]. An accurate grammar that describes the current implementation would be twice as complicated, because FunctionBody would have to be redefined. I want the feature to be as simple as possible to understand, so I didn't think it was worth it.

There has also been mention of the possibility of improving the implementation of contracts to allow separate compilation, in which case the signature, plus contracts, could some day appear without the body. I wanted to define the new expressions to accommodate this possibility.

[1] https://dlang.org/spec/grammar.html#FunctionBody

On 7/21/17 6:51 AM, Mike Parker wrote:
> DIP 1009 is titled "Improve Contract Usability".

For out contracts that use the return identifier, could the keyword "return" be used?

    out(return > 0)

One possible problem with this syntax is a future where functions could have multiple return values...

On Friday, 21 July 2017 at 18:35:53 UTC, David Gileadi wrote:
> On 7/21/17 6:51 AM, Mike Parker wrote:
>> DIP 1009 is titled "Improve Contract Usability".
>
> For out contracts that use the return identifier, could the keyword "return" be used?
>
>     out(return > 0)
>
> One possible problem with this syntax is a future where functions could have multiple return values...

No, see Round 1 discussion [1]

[1] http://forum.dlang.org/post/oihbot$134s$1@digitalmars.com

On 7/21/17 11:41 AM, Moritz Maxeiner wrote:
> On Friday, 21 July 2017 at 18:35:53 UTC, David Gileadi wrote:
>> On 7/21/17 6:51 AM, Mike Parker wrote:
>>> DIP 1009 is titled "Improve Contract Usability".
>>
>> For out contracts that use the return identifier, could the keyword "return" be used?
>>
>>     out(return > 0)
>>
>> One possible problem with this syntax is a future where functions could have multiple return values...
> 
> No, see Round 1 discussion [1]
> 
> [1] http://forum.dlang.org/post/oihbot$134s$1@digitalmars.com

Ah, thanks--I missed that.

On Friday, 21 July 2017 at 13:51:05 UTC, Mike Parker wrote:
> DIP 1009 is titled "Improve Contract Usability".
>
> [...]
>
> Destroy!

I really like how the syntax turned out. My only remaining peeve is the `ContractParameters` nomenclature in the grammar section, because it implies that asserts are contracts. If contracts and asserts share a common grammar rule, imho the rule's name should be agnostic to either of them, like `ConditionalParameters`. In any case, it's a complaint on a very high level and arguably not relevant to any end user (as usually no one other than compiler people look at the grammar rules, anyway).
Thanks for the time invested in the DIP!

On Friday, 21 July 2017 at 18:55:08 UTC, Moritz Maxeiner wrote:

> I really like how the syntax turned out. My only remaining peeve is the `ContractParameters` nomenclature in the grammar section, because it implies that asserts are contracts.

Maybe I should have stuck with AssertParameters. That can easily be fixed.

On Friday, 21 July 2017 at 19:19:47 UTC, MysticZach wrote:
> On Friday, 21 July 2017 at 18:55:08 UTC, Moritz Maxeiner wrote:
>
>> I really like how the syntax turned out. My only remaining peeve is the `ContractParameters` nomenclature in the grammar section, because it implies that asserts are contracts.
>
> Maybe I should have stuck with AssertParameters. That can easily be fixed.

I know this is being pedantic to an annoying degree (sorry), but that would just invert the implication's direction, i.e. "it implies that contracts are asserts". The only way I can think of right now to get rid of the implication would be to choose a name that is agnostic to either of them.