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
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 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 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.
But there is no overhead or something else _if_ i put the type,
or?
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
make -fwin32.mak release
That simple... :) Many thanks!
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
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: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
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 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.
You'll also have to change the line that says
expect(TOKsemicolon);
In what? comment out?
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) {.
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
Which is easy.
Even on Windows? :O
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
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
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.
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. :/
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.
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 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 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
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 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
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: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.
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 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 ';'
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 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
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
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 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
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.
37 matches
Mail list logo
