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%
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
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 {}
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 {...}`,
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
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.
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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?
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
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
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'
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
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 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.
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
32 matches
Mail list logo
