A friend of mine ask me why D's foreach isn't like C#
Means, why is it like
int[] arr = [1, 2, 3];
foreach (int val; arr) {
and not
foreach (int val in arr) {
which it is more intuitive.
I could give him no clever answer to, so maybe someone here knows
the reasons.
On 06/29/2012 12:47 PM, Namespace wrote:
> A friend of mine ask me why D's foreach isn't like C#
>
> Means, why is it like
> int[] arr = [1, 2, 3];
>
> foreach (int val; arr) {
>
> and not
> foreach (int val in arr) {
>
> which it is more intuitive.
>
> I could give him no clever answer to, so
Namespace:
A friend of mine ask me why D's foreach isn't like C#
In D you often omit the type:
foreach (val; arr) {
Using "in" is better for the human programmers. But D is largely
designed to make D compilers too happy. I think Walter said that
the semicolon was preferred because it simpli
On Fri, 29 Jun 2012 12:47:28 +0200, Namespace wrote:
> A friend of mine ask me why D's foreach isn't like C#
>
> Means, why is it like int[] arr = [1, 2, 3];
>
> foreach (int val; arr) {
>
> and not foreach (int val in arr) {
>
> which it is more intuitive.
>
> I could give him no clever answ
On 06/29/2012 12:47 PM, Namespace wrote:
A friend of mine ask me why D's foreach isn't like C#
Means, why is it like
int[] arr = [1, 2, 3];
foreach (int val; arr) {
foreach(val; arr) {
and not
foreach (int val in arr) {
which it is more intuitive.
To someone coming from C#, yes.
I co
Timon Gehr:
Just because. This does not matter.
Now and then I write foreach(x;y;data) or foreach(x,y,data) or
foreach(x;y,data). "in" avoids some of those little mistakes.
Bye,
bearophile
On 06/29/2012 01:01 PM, bearophile wrote:
Namespace:
A friend of mine ask me why D's foreach isn't like C#
In D you often omit the type:
foreach (val; arr) {
Using "in" is better for the human programmers.
Certainly not. (except if 'human' means 'python' or 'C#'.)
It is just as good as ';'
On 06/29/2012 04:16 PM, bearophile wrote:
Timon Gehr:
Just because. This does not matter.
Now and then I write foreach(x;y;data)
error: found ';' when expecting ')'
or foreach(x,y,data) or
error: found ')' when expecting ';'
foreach(x;y,data).
error: undefined identifier y
"in" av
On 06/29/2012 04:23 PM, Timon Gehr wrote:
...
foreach(x;y,data).
error: undefined identifier y
BTW, it would certainly be better if this didn't actually pass the parser.
Timon Gehr:
foreach(x in y,data)
There is no way to avoid all possible mistakes, but it's easier
to mistake a ";" for a ",", than mistake a "in" for a ",".
"in" is used for this purpose in Python, C#, and probably other
languages because it's more readable than an arbitrary symbol
like ";
On 06/29/2012 04:34 PM, bearophile wrote:
Timon Gehr:
foreach(x in y,data)
There is no way to avoid all possible mistakes, but it's easier to
mistake a ";" for a ",", than mistake a "in" for a ",".
I don't think optimizing the grammar for error cases that are not even
compilable code is wo
On Friday, June 29, 2012 16:34:33 bearophile wrote:
> Timon Gehr:
> > foreach(x in y,data)
>
> There is no way to avoid all possible mistakes, but it's easier
> to mistake a ";" for a ",", than mistake a "in" for a ",".
>
> "in" is used for this purpose in Python, C#, and probably other
> languag
On Friday, June 29, 2012 12:47:28 Namespace wrote:
> A friend of mine ask me why D's foreach isn't like C#
>
> Means, why is it like
> int[] arr = [1, 2, 3];
>
> foreach (int val; arr) {
>
> and not
> foreach (int val in arr) {
>
> which it is more intuitive.
>
> I could give him no clever ans
It wasn't my intention to start a syntax war. :D
But i must agree, that "in" is a lot more readable as ";". Event
":" ist more readable as ";". But i just would know the real
reason to this decision. Tanks to all. :)
But why correct a few guys here my code?
foreach (int val; is the same as fore
On 06/29/2012 06:09 PM, Namespace wrote:
It wasn't my intention to start a syntax war. :D
But i must agree, that "in" is a lot more readable as ";". Event ":" ist
more readable as ";". But i just would know the real reason to this
decision. Tanks to all. :)
But why correct a few guys here my code
It is redundant.
But informative.
Search for TOKforeach in parse.c and change the TOKsemicolon's
around there to TOKin's. If you want to allow both, that should
be
straightforward as well.
I will try.
You mean just change line 3817 to
if (t->value == TOKcomma || t->value == TOKsemicolon || t->value
== TOKin) ?
But know i have to rebuild dmd (i use windows), and i never did
this before. :/
You mean line 3817 change to
if (t->value == TOKcomma || t->value == TOKsemicolon || t->value
== TOKin) ?
But i have to rebuild dmd or not? I'm a windows user and I never
build dmd on my own.
Am 29.06.2012 18:23, schrieb Namespace:
You mean line 3817 change to
if (t->value == TOKcomma || t->value == TOKsemicolon || t->value ==
TOKin) ?
But i have to rebuild dmd or not? I'm a windows user and I never build
dmd on my own.
Yes, you have to recompile DMD
On Friday, 29 June 2012 at 16:27:23 UTC, Namespace wrote:
You mean just change line 3817 to
if (t->value == TOKcomma || t->value == TOKsemicolon ||
t->value == TOKin) ?
But know i have to rebuild dmd (i use windows), and i never did
this before. :/
Which is easy. I write a guide as soon as ti
Which is easy.
Even on Windows? :O
On Friday, 29 June 2012 at 17:08:36 UTC, Namespace wrote:
Which is easy.
Even on Windows? :O
I tried with win32.mak in src/dmd and i get a dmd.exe. But the
compiler still says
"found 'in' when expecting ';'!" if i try to write foreach (val
in vals) {.
Have i edit the wrong line in paste.c
On 06/29/2012 06:27 PM, Namespace wrote:
You mean just change line 3817 to
if (t->value == TOKcomma || t->value == TOKsemicolon || t->value ==
TOKin) ?
But know i have to rebuild dmd (i use windows), and i never did this
before. :/
You'll also have to change the line that says expect(TOKsemicol
On 06/29/2012 07:47 PM, Namespace wrote:
On Friday, 29 June 2012 at 17:08:36 UTC, Namespace wrote:
Which is easy.
Even on Windows? :O
I tried with win32.mak in src/dmd and i get a dmd.exe. But the compiler
still says
"found 'in' when expecting ';'!" if i try to write foreach (val in vals) {.
You'll also have to change the line that says
expect(TOKsemicolon);
In what? comment out?
On 06/29/2012 07:50 PM, Namespace wrote:
You'll also have to change the line that says expect(TOKsemicolon);
In what? comment out?
Looking at some other parts of the parse.c source reveals that
if(token.value == TOKin) nextToken(); else expect(TOKsemicolon);
might get you going.
On Friday, 29 June 2012 at 17:55:57 UTC, Timon Gehr wrote:
On 06/29/2012 07:50 PM, Namespace wrote:
You'll also have to change the line that says
expect(TOKsemicolon);
In what? comment out?
Looking at some other parts of the parse.c source reveals that
if(token.value == TOKin) nextToken();
On 06/29/2012 08:04 PM, Namespace wrote:
On Friday, 29 June 2012 at 17:55:57 UTC, Timon Gehr wrote:
On 06/29/2012 07:50 PM, Namespace wrote:
You'll also have to change the line that says expect(TOKsemicolon);
In what? comment out?
Looking at some other parts of the parse.c source reveals th
My bad:
Replacing the line with the following, together with the other
change you made, works:
if(token.value == TOKin) nextToken(); else check(TOKsemicolon);
Impressive, thanks a lot, sometimes I'm a bit stupid. :)
Last question: It works fine, but i'm getting now "DMD v2.059
DEBUG" if i
On 06/29/2012 08:18 PM, Namespace wrote:
My bad:
Replacing the line with the following, together with the other change
you made, works:
if(token.value == TOKin) nextToken(); else check(TOKsemicolon);
Impressive, thanks a lot, sometimes I'm a bit stupid. :)
Last question: It works fine, but i
make -fwin32.mak release
That simple... :) Many thanks!
On Friday, June 29, 2012 18:16:23 Namespace wrote:
> > It is redundant.
>
> But informative.
It's very common in D to not put the type unless it's absolutely necessary
(e.g. use auto everywhere). This can be both good and bad for code readability
and maintenance, but it's particularly useful wi
But there is no overhead or something else _if_ i put the type,
or?
On 06/29/2012 09:51 PM, Namespace wrote:
But there is no overhead or something else _if_ i put the type, or?
There is a slight typing and compilation overhead. Nothing significant.
On Friday, June 29, 2012 21:51:20 Namespace wrote:
> But there is no overhead or something else _if_ i put the type,
> or?
No. It's like auto. The type is inferred. It's all statically typed and
strongly typed. It's not like it figures out the type at runtime or anything
like that. It's all done
On Friday, 29 June 2012 at 19:52:33 UTC, Timon Gehr wrote:
On 06/29/2012 09:51 PM, Namespace wrote:
But there is no overhead or something else _if_ i put the
type, or?
There is a slight typing and compilation overhead. Nothing
significant.
You missed a slight reading overhead.
On 06/29/2012 10:02 PM, Roman D. Boiko wrote:
On Friday, 29 June 2012 at 19:52:33 UTC, Timon Gehr wrote:
On 06/29/2012 09:51 PM, Namespace wrote:
But there is no overhead or something else _if_ i put the type, or?
There is a slight typing and compilation overhead. Nothing significant.
You m
37 matches
Mail list logo
