On Tuesday, 25 July 2017 at 07:58:13 UTC, Olivier FAURE wrote:
>
> 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.

We weren't speaking of rejected proposals, but of previously reviewed drafts. Rejected proposals already include a summary of why they were rejected. You can a list of all DIPs submitted under the current process, including links and their current status, at:

https://github.com/dlang/DIPs/blob/master/DIPs/README.md

And please everyone, I'm happy to discuss ideas to improve the DIP process, but let's not do it in the review threads. Email me, start a new thread, whatever, but please try to keep review threads on the topic at hand. Thanks!

On Tuesday, 25 July 2017 at 09:53:02 UTC, Mike Parker wrote:
> On Tuesday, 25 July 2017 at 07:58:13 UTC, Olivier FAURE wrote:
>> 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.
>
> We weren't speaking of rejected proposals, but of previously reviewed drafts. Rejected proposals already include a summary of why they were rejected. You can a list of all DIPs submitted under the current process, including links and their current status, at:
>
> https://github.com/dlang/DIPs/blob/master/DIPs/README.md

I... think you misunderstood me? I shouldn't have used the word 'proposals', I should have said 'suggestions'.

What I meant was "I think it would be better for the current version of DIP 1009 to include a 'Rejected alternative syntaxes' that would include a summary of the previously discussed suggestions for improving contract readability."

MysticZach argues that such a section would be pointless since the language authors read the previous version of DIP 1009, but I still think adding it would be a good idea (for posterity and to streamline discussions in this thread).

On Wednesday, 26 July 2017 at 08:12:39 UTC, Olivier FAURE wrote:
> I... think you misunderstood me? I shouldn't have used the word 'proposals', I should have said 'suggestions'.
>
> What I meant was "I think it would be better for the current version of DIP 1009 to include a 'Rejected alternative syntaxes' that would include a summary of the previously discussed suggestions for improving contract readability."
>
> MysticZach argues that such a section would be pointless since the language authors read the previous version of DIP 1009, but I still think adding it would be a good idea (for posterity and to streamline discussions in this thread).

I don't know. DIPs have both a forward-looking and a backward-looking aspect. The forward is to convince the language authors of the need/value of a specific language change. The backward is to record a history of discussions so that people can learn why things are the way they are. They are both valuable in their own way, but I think the forward-looking aspect is more valuable. I'd like some guidance from the leadership as to the important of the backward-looking aspect of DIPs. For example, DIP1003 was actually rewritten to excise the alternatives and keep only the one adopted. The motive given was that people looking for the history could examine prior versions of the DIP. I guess the motive is that too much history can end up cluttering the important information.

That said, I think that making good decisions for the language far outweighs any concerns about DIPs themselves. So we should really be focusing on that.

On Tuesday, 25 July 2017 at 07:48:39 UTC, Andrea Fontana wrote:
> 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

It's another viable option, but it doesn't seem to stand out much from the crowd. Most people, including me, seem to think `out(x; x > 0)` and `out(; y > 0)` are the "least imperfect" option. I suspect they would win if put to a vote. Maybe the leadership can come up with something better. People will get used to whatever is selected. I just like the foreach version because it's simple and concise. I also don't think the ambiguous `out(x > 0)` syntax is that bad for non-return variables. But I can also see why that's suboptimal from a design point of view.

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

I think the proposed in/out expression contracts should require pure expressions. In the rare case that impurity is required, the old syntax can be used. This makes the proposal more useful. Otherwise, the expression would have to be awkwardly wrapped in `()pure => expr` code to enforce this (without requiring purity of function body too). It's too late to require purity for existing contract syntax, but we have an opportunity here.

One option to solve the out contract ambiguity and aid parsing by tools is to require 'do' after out contract expressions. It allows the syntax `out(expression) do {...}`, even when expression is a single identifier that should be interpreted as a boolean expression.

On 28.07.2017 13:04, Nick Treleaven 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
> 
> I think the proposed in/out expression contracts should require pure expressions. In the rare case that impurity is required, the old syntax can be used. This makes the proposal more useful. Otherwise, the expression would have to be awkwardly wrapped in `()pure => expr` code to enforce this (without requiring purity of function body too). It's too late to require purity for existing contract syntax, but we have an opportunity here. ...

No, please. Even the fact that 'out' implicitly applies 'const' is annoying enough, and there is absolutely no good reason to make the two notations behave differently.

On Friday, 28 July 2017 at 11:04:23 UTC, Nick Treleaven wrote:
> One option to solve the out contract ambiguity and aid parsing by tools is to require 'do' after out contract expressions. It allows the syntax `out(expression) do {...}`, even when expression is a single identifier that should be interpreted as a boolean expression.

One of the main goals of this DIP is to eliminate the need for `body/do` in the common case. It would significantly reduce this DIP's value if it couldn't do that, IMO.

On Friday, 28 July 2017 at 16:44:24 UTC, MysticZach wrote:
> On Friday, 28 July 2017 at 11:04:23 UTC, Nick Treleaven wrote:
>> One option to solve the out contract ambiguity and aid parsing by tools is to require 'do' after out contract expressions. It allows the syntax `out(expression) do {...}`, even when expression is a single identifier that should be interpreted as a boolean expression.
>
> One of the main goals of this DIP is to eliminate the need for `body/do` in the common case. It would significantly reduce this DIP's value if it couldn't do that, IMO.

This*1000.
Having a keyword delimit the end of an optional is both redundant and inconsistent with virtually every other rule in the D grammar (except old contract syntax). It's one of the (two) major reasons why I don't use the original contract syntax.

On Friday, 28 July 2017 at 16:44:24 UTC, MysticZach wrote:
> On Friday, 28 July 2017 at 11:04:23 UTC, Nick Treleaven wrote:
>> One option to solve the out contract ambiguity and aid parsing by tools is to require 'do' after out contract expressions.

BTW `do` would only be required before the {} function body - further `in` and `out` clauses also can be used to disambiguate, see below.

> One of the main goals of this DIP is to eliminate the need for `body/do` in the common case. It would significantly reduce this DIP's value if it couldn't do that, IMO.

This is subjective. If you put `do` on the end of the line, it is trivial:

in(x > 4)
out(works)
out(r; r.test)
out(flag) do
{
  // body
}

On Friday, 28 July 2017 at 16:58:41 UTC, Moritz Maxeiner wrote:
> Having a keyword delimit the end of an optional is both redundant and inconsistent

You are arguing against the current syntax, not my proposal. In my case the `do` keyword would be disambiguating between out expressions and out blocks. It is not redundant, by the same logic I could argue that `;` in `(; identifier)` is redundant. They are different valid options of disambiguation.