Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 2 Begins
On Monday, 31 July 2017 at 09:55:22 UTC, Nick Treleaven wrote:
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
}
The common case is for `out` contracts to test for the return
variable. Something like 90% will therefore look like:
int fun(int x)
out(r; r > 0)
{
}
So it's the uncommon case we're trying to solve for. Requiring
`do` in precisely one case, which is the rare case in which the
`out` test has only one identifier, and therefore can't be
disambiguated from existing `out` contracts, is a solution to
that problem. It's seems like a complicated one. To me, it's
simpler to simply require the `;` because it's the uncommon case
to begin with, and everyone will know what it means because
they'll be used to seeing `out(r; r > 0)`.
That said, `do` can solve the loophole with the alternative
ambiguous syntax. For example:
int fun(ref int x, ref int y, ref int z)
out(x) // fine, followed by another contract
out(y != 0) // fine, multiple tokens, unambiguous
out(z) do // fine, followed by `do`
{
}
If you forget to add the `do` there is an inevitable parsing
error, so it's not that bad even in the worst case. The error can
be fixed by changing `out(z)` to `out(z != 0)`, or to `out(z) do`
as you suggest. `do` is only going to be valuable in that one
case, though. I'd say it depends where the language designers
want to pay the cost of solving the problem. Either pay it up
front with the ugliness of the foreach syntax, or pay it in
complexity with the different cases of the ambiguous syntax.
Because it's a programming language and not a sports car, I'd
probably choose the consistency of the foreach syntax over the
attractiveness of the ambiguous syntax. But there's no clear
winner, IMO.
Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 2 Begins
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.
Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 2 Begins
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
}
Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 2 Begins
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.
Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 2 Begins
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.
Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 2 Begins
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.
Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 2 Begins
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.
Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 2 Begins
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.
Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 2 Begins
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.
Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 2 Begins
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).
Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 2 Begins
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!
Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 2 Begins
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
Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 2 Begins
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.
Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 2 Begins
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
Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 2 Begins
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
Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 2 Begins
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
Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 2 Begins
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);
}
Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 2 Begins
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/gjtsfysvtyxcfcmuu...@forum.dlang.org
Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 2 Begins
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
Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 2 Begins
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.
Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 2 Begins
On Fri, Jul 21, 2017 at 01:51:05PM +, 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 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.
Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 2 Begins
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.
Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 2 Begins
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.
Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 2 Begins
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!
Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 2 Begins
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.
Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 2 Begins
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
Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 2 Begins
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...
Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 2 Begins
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
Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 2 Begins
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.
Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 2 Begins
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.
DIP 1009--Improve Contract Usability--Preliminary Review Round 2 Begins
DIP 1009 is titled, "Improve Contract Usability". The second preliminary review round is now underway. http://forum.dlang.org/post/luhdbjnsmfomtgpyd...@forum.dlang.org As a reminder, the first preliminary review round for DIP 1011 is ongoing and has one week remaining. http://forum.dlang.org/post/topmfucguenqpucsb...@forum.dlang.org
DIP 1009--Improve Contract Usability--Preliminary Review Round 2 Begins
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!
