On Thursday, 5 July 2018 at 09:45:44 UTC, Basile B. wrote:
On Wednesday, 4 July 2018 at 14:37:49 UTC, Timon Gehr wrote:
On 24.06.2018 13:27, Basile B. wrote:
FYI this works fine, as expected it's just some small parser
changes.
I didn't touch to for and foreach for now. I think that
On Wednesday, 4 July 2018 at 14:37:49 UTC, Timon Gehr wrote:
On 24.06.2018 13:27, Basile B. wrote:
FYI this works fine, as expected it's just some small parser
changes.
I didn't touch to for and foreach for now. I think that
SwitchStatement is a candidate too.
On Wednesday, 4 July 2018 at 14:37:49 UTC, Timon Gehr wrote:
if (a+b)*c == d { ... }
Error: found `{` when expecting `;` following statement
Adding the semi-colon, `*c == d;` would likely cause:
Error: `*c == d` has no effect
Also multiplying (a+b) by a pointer is illegal, and c is probably
On 24.06.2018 13:27, Basile B. wrote:
FYI this works fine, as expected it's just some small parser changes.
I didn't touch to for and foreach for now. I think that SwitchStatement
is a candidate too.
https://github.com/BBasile/dmd/commit/5455a65c8fdee5a6d198782d1f168906b59e6d3d
if (a+b)*c
On Monday, 2 July 2018 at 20:28:06 UTC, Seb wrote:
On Sunday, 1 July 2018 at 12:02:03 UTC, Nick Treleaven wrote:
On Sunday, 24 June 2018 at 23:40:56 UTC, Timoses wrote:
The others may be rewritten to not have a leading "!" as
well, e.g.
if (!(t1.ty == Tarray && t2.ty == Tarray &&
On Saturday, 23 June 2018 at 04:45:07 UTC, user1234 wrote:
There is this case that requires parens:
if a && b c;
Is there a missing && or not ? It seems obvious for a human but
compiler parsers are "apparatchiks", i.e rules are rules. That
being said this would work by allowing parens
On Sunday, 1 July 2018 at 12:02:03 UTC, Nick Treleaven wrote:
On Sunday, 24 June 2018 at 23:40:56 UTC, Timoses wrote:
The others may be rewritten to not have a leading "!" as well,
e.g.
if (!(t1.ty == Tarray && t2.ty == Tarray && needsDirectEq(t1,
t2))
if (t1.ty != Tarray || t2.ty !=
On Monday, 25 June 2018 at 12:19:15 UTC, aliak wrote:
On Monday, 25 June 2018 at 10:38:49 UTC, Basile B. wrote:
On Monday, 25 June 2018 at 10:36:46 UTC, Basile B. wrote:
On Sunday, 24 June 2018 at 23:08:15 UTC, aliak wrote:
Wow nice, that was quick, would it be much more to make it
so that
On Sunday, 24 June 2018 at 23:40:56 UTC, Timoses wrote:
The others may be rewritten to not have a leading "!" as well,
e.g.
if (!(t1.ty == Tarray && t2.ty == Tarray && needsDirectEq(t1,
t2))
if (t1.ty != Tarray || t2.ty != Tarray || ...)
Yes, but you might make a mistake, and sometimes it
On Monday, 25 June 2018 at 10:38:49 UTC, Basile B. wrote:
On Monday, 25 June 2018 at 10:36:46 UTC, Basile B. wrote:
On Sunday, 24 June 2018 at 23:08:15 UTC, aliak wrote:
Wow nice, that was quick, would it be much more to make it so
that braces are required with if statements that do not
On Sunday, 24 June 2018 at 23:08:15 UTC, aliak wrote:
On Sunday, 24 June 2018 at 11:27:12 UTC, Basile B. wrote:
On Saturday, 23 June 2018 at 06:24:29 UTC, Basile B. wrote:
On Saturday, 23 June 2018 at 06:18:53 UTC, user1234 wrote:
On Saturday, 23 June 2018 at 05:09:13 UTC, aedt wrote:
On
On Monday, 25 June 2018 at 10:36:46 UTC, Basile B. wrote:
On Sunday, 24 June 2018 at 23:08:15 UTC, aliak wrote:
On Sunday, 24 June 2018 at 11:27:12 UTC, Basile B. wrote:
On Saturday, 23 June 2018 at 06:24:29 UTC, Basile B. wrote:
On Saturday, 23 June 2018 at 06:18:53 UTC, user1234 wrote:
On
On Sunday, 24 June 2018 at 22:03:13 UTC, Dennis wrote:
if (!("key" in dict)) {...}
if ("key" !in dict) {...}
At least that one has a shorter form. The others may be rewritten
to not have a leading "!" as well, e.g.
if (!(t1.ty == Tarray && t2.ty == Tarray && needsDirectEq(t1,
t2))
if
On Sunday, 24 June 2018 at 22:25:43 UTC, Jonathan M Davis wrote:
On Sunday, June 24, 2018 22:03:13 Dennis via Digitalmars-d
wrote:
On Saturday, 23 June 2018 at 02:14:04 UTC, Jonathan M Davis
wrote:
> [...]
I don't see why allowing one to omit the parens makes porting
C code harder.
It
On Sunday, 24 June 2018 at 11:27:12 UTC, Basile B. wrote:
On Saturday, 23 June 2018 at 06:24:29 UTC, Basile B. wrote:
On Saturday, 23 June 2018 at 06:18:53 UTC, user1234 wrote:
On Saturday, 23 June 2018 at 05:09:13 UTC, aedt wrote:
On Saturday, 23 June 2018 at 04:45:07 UTC, user1234 wrote:
On Sunday, June 24, 2018 22:03:13 Dennis via Digitalmars-d wrote:
> On Saturday, 23 June 2018 at 02:14:04 UTC, Jonathan M Davis wrote:
> > In general, C code is supposed to be either valid D code or not
> > compile in order to making porting it easier. Getting rid of
> > the parens wouldn't break
On Saturday, 23 June 2018 at 02:14:04 UTC, Jonathan M Davis wrote:
In general, C code is supposed to be either valid D code or not
compile in order to making porting it easier. Getting rid of
the parens wouldn't break that, but it _would_ make it so that
it's more work to port C code to D when
On Saturday, 23 June 2018 at 06:24:29 UTC, Basile B. wrote:
On Saturday, 23 June 2018 at 06:18:53 UTC, user1234 wrote:
On Saturday, 23 June 2018 at 05:09:13 UTC, aedt wrote:
On Saturday, 23 June 2018 at 04:45:07 UTC, user1234 wrote:
On Saturday, 23 June 2018 at 01:27:30 UTC, aedt wrote:
for
On Sunday, 24 June 2018 at 08:30:28 UTC, Jacob Carlborg wrote:
On 2018-06-23 14:34, Tobias Müller wrote:
AFAIK the if and else branches in Rust always have to be
enclosed in curly
braces because of this.
I don't remember the exact ambiguity though.
There's an ambiguity between the condition
On 2018-06-23 14:34, Tobias Müller wrote:
AFAIK the if and else branches in Rust always have to be enclosed in curly
braces because of this.
I don't remember the exact ambiguity though.
There's an ambiguity between the condition and the body. There needs to
be some kind of symbol to separate
On Saturday, 23 June 2018 at 09:19:45 UTC, user1234 wrote:
...Forcing Curly braces is nice, logic and natural imo.
The operator brackets themselves are a separate construction. In
addition, the more structured the code, the less they are needed.
In my code, most of the loops and branches
aedt wrote:
> Modern languages have already
> dropped this requirement (i.e. Rust, Nim) and I don't see any
> reason not to do so.
AFAIK the if and else branches in Rust always have to be enclosed in curly
braces because of this.
I don't remember the exact ambiguity though.
On Saturday, 23 June 2018 at 09:19:45 UTC, user1234 wrote:
On Saturday, 23 June 2018 at 08:07:23 UTC, Jacob Carlborg wrote:
On 2018-06-23 03:27, aedt wrote:
for line in stdin.lines() {}
if condition {}
while condition {}
for init; condition; op {}
What's the rationale of keeping the
On Saturday, 23 June 2018 at 08:07:23 UTC, Jacob Carlborg wrote:
On 2018-06-23 03:27, aedt wrote:
for line in stdin.lines() {}
if condition {}
while condition {}
for init; condition; op {}
What's the rationale of keeping the requirement that the
condition of
if/for/while must be wrapped
On 2018-06-23 03:27, aedt wrote:
for line in stdin.lines() {}
if condition {}
while condition {}
for init; condition; op {}
What's the rationale of keeping the requirement that the condition of
if/for/while must be wrapped with a parenthesis (other than keeping
parser simple)? Modern
On Saturday, 23 June 2018 at 06:18:53 UTC, user1234 wrote:
On Saturday, 23 June 2018 at 05:09:13 UTC, aedt wrote:
On Saturday, 23 June 2018 at 04:45:07 UTC, user1234 wrote:
On Saturday, 23 June 2018 at 01:27:30 UTC, aedt wrote:
for line in stdin.lines() {}
if condition {}
while condition {}
On Saturday, 23 June 2018 at 05:09:13 UTC, aedt wrote:
On Saturday, 23 June 2018 at 04:45:07 UTC, user1234 wrote:
On Saturday, 23 June 2018 at 01:27:30 UTC, aedt wrote:
for line in stdin.lines() {}
if condition {}
while condition {}
for init; condition; op {}
What's the rationale of
On 06/22/2018 09:27 PM, aedt wrote:
for line in stdin.lines() {}
if condition {}
while condition {}
for init; condition; op {}
What's the rationale of keeping the requirement that the condition of
if/for/while must be wrapped with a parenthesis (other than keeping
parser simple)? Modern
On Saturday, 23 June 2018 at 04:45:07 UTC, user1234 wrote:
On Saturday, 23 June 2018 at 01:27:30 UTC, aedt wrote:
for line in stdin.lines() {}
if condition {}
while condition {}
for init; condition; op {}
What's the rationale of keeping the requirement that the
condition of if/for/while
On Saturday, 23 June 2018 at 01:27:30 UTC, aedt wrote:
for line in stdin.lines() {}
if condition {}
while condition {}
for init; condition; op {}
What's the rationale of keeping the requirement that the
condition of if/for/while must be wrapped with a parenthesis
(other than keeping
On Saturday, June 23, 2018 01:27:30 aedt via Digitalmars-d wrote:
> for line in stdin.lines() {}
>
> if condition {}
>
> while condition {}
>
> for init; condition; op {}
>
>
> What's the rationale of keeping the requirement that the
> condition of if/for/while must be wrapped with a parenthesis
>
for line in stdin.lines() {}
if condition {}
while condition {}
for init; condition; op {}
What's the rationale of keeping the requirement that the
condition of if/for/while must be wrapped with a parenthesis
(other than keeping parser simple)? Modern languages have already
dropped this
32 matches
Mail list logo
