Posted a pull request:
https://github.com/D-Programming-Language/phobos/pull/678
With the patch, following code works as expected.
import std.container;
import std.stdio;
import std.algorithm;
void main()
{
Array!int arr;
arr.length = 3;
foreach(ref a; arr) // requre 'ref'
On 7/10/12 4:29 AM, kenji hara wrote:
Posted a pull request:
https://github.com/D-Programming-Language/phobos/pull/678
Hmm, that has a couple of issues.
First, map that modifies things in place is a bug more often than a
feature given that the caller of map may use front() an arbitrary
2012/7/10 Andrei Alexandrescu seewebsiteforem...@erdani.org:
On 7/10/12 4:29 AM, kenji hara wrote:
Posted a pull request:
https://github.com/D-Programming-Language/phobos/pull/678
Hmm, that has a couple of issues.
First, map that modifies things in place is a bug more often than a feature
On 7/10/12 10:32 AM, kenji hara wrote:
OK. I know the past discussion about 'sealed container' so I can agree
with your argument.
Then I'll close the pull request.
Sounds good for now but let's keep in mind the possibility of
restricting ref returns. At that point we can open up ref returns
On 07/10/2012 05:01 PM, Andrei Alexandrescu wrote:
On 7/10/12 10:32 AM, kenji hara wrote:
OK. I know the past discussion about 'sealed container' so I can agree
with your argument.
Then I'll close the pull request.
Sounds good for now but let's keep in mind the possibility of
restricting ref
On 7/10/12 11:03 AM, Timon Gehr wrote:
On 07/10/2012 05:01 PM, Andrei Alexandrescu wrote:
On 7/10/12 10:32 AM, kenji hara wrote:
OK. I know the past discussion about 'sealed container' so I can agree
with your argument.
Then I'll close the pull request.
Sounds good for now but let's keep in
On Tuesday, 10 July 2012 at 14:19:04 UTC, Andrei Alexandrescu
wrote:
...
Second, the return by value from Array is intentional and has
to do with sealing. Array is intended to never escape the
addresses of its elements. That way, the collection is sealed
in the sense there can never be
On Tuesday, July 10, 2012 23:25:41 monarch_dodra wrote:
On Tuesday, 10 July 2012 at 14:19:04 UTC, Andrei Alexandrescu
wrote:
...
Second, the return by value from Array is intentional and has
to do with sealing. Array is intended to never escape the
addresses of its elements. That
On 07/10/2012 11:51 PM, Jonathan M Davis wrote:
On Tuesday, July 10, 2012 23:25:41 monarch_dodra wrote:
...
And more generally, how would code like this _ever_ work?
Array!int arr
foreach(ref a; arr)
a += 5;
Since there is no mechanism to pass the op to front?
I believe that according to
On 07/10/2012 05:07 PM, Andrei Alexandrescu wrote:
On 7/10/12 11:03 AM, Timon Gehr wrote:
On 07/10/2012 05:01 PM, Andrei Alexandrescu wrote:
On 7/10/12 10:32 AM, kenji hara wrote:
OK. I know the past discussion about 'sealed container' so I can agree
with your argument.
Then I'll close the
On Wednesday, July 11, 2012 00:15:34 Timon Gehr wrote:
On 07/10/2012 11:51 PM, Jonathan M Davis wrote:
On Tuesday, July 10, 2012 23:25:41 monarch_dodra wrote:
...
And more generally, how would code like this _ever_ work?
Array!int arr
foreach(ref a; arr)
a += 5;
Since there is
On Monday, 2 July 2012 at 12:44:59 UTC, monarch_dodra wrote:
...
I opened this thread a week ago, and got little no feed back.
I've realized since:
1) map was a bad example, since it actually returns a new range
(does not modify the underlying values), so the output was normal
2) I pasted
On 02/07/12 18:43, bearophile wrote:
It's not a bug, it's caused by how ranges like retro work. retro yields a single
item. In D you can't overload on return values, so foreach can't try to call a
second retro.front overload that yields an (index,item) tuple (that later
foreach is able to unpack
On 02/07/12 18:57, kenji hara wrote:
D does not provide index for the range iteration.
Instead, you can create 'zipped' range.
Oh, cool. That's a nice feature that I can think of other uses for ... :-)
On Monday, 2 July 2012 at 12:44:59 UTC, monarch_dodra wrote:
I think this is a pretty serious bug: when one writes:
foreach(ref a, range), the underlying (ref'd) object will
ONLY get modified if the range object provides a ref T
front() method.
Somethig related, zip(a,b) allows to sort the
Running this code
Sorry, should be attempting to compile this code.
On 07/02/2012 05:36 PM, Joseph Rushton Wakeling wrote:
Hello all,
A problem with the retro function from std.range -- although it
apparently operates on a bidirectional range, it fails when used with
foreach requesting both value and index. Running this code:
What would be your expected output?
From the inner to the outer expression:
First the range is reversed and then the elements of this range
are enumerated.
Joseph Rushton Wakeling:
double[] a = [ 0, 1, 2, 3, 4, 5 ];
foreach(i, x; retro(a))
writeln(i, \t, x);
It's not a bug, it's caused by how ranges like retro work. retro
yields a single item. In D you can't overload on return values,
so foreach can't try to call a
On 02/07/12 17:48, Timon Gehr wrote:
What would be your expected output?
I'd expect to see
0 5
1 4
2 3
3 2
4 1
5 0
i.e. as if I was foreach-ing over an array with the same values in inverted
order.
D does not provide index for the range iteration.
Instead, you can create 'zipped' range.
void main() {
auto intr = sequence!n(); // 0, 1, 2, ...
double[] a = [ 0, 1, 2, 3, 4, 5 ];
foreach(i, x; zip(intr, retro(a)))
writeln(i, \t, x);
}
zip(intr, retro(a)) is a
On Monday, 2 July 2012 at 16:49:06 UTC, Joseph Rushton Wakeling
wrote:
On 02/07/12 17:48, Timon Gehr wrote:
What would be your expected output?
I'd expect to see
0 5
1 4
2 3
3 2
4 1
5 0
i.e. as if I was foreach-ing over an array with the same values
in inverted
bearophile , dans le message (digitalmars.D:171013), a écrit :
It's not a bug, it's caused by how ranges like retro work. retro
yields a single item. In D you can't overload on return values,
But you can overload OpApply.
--
Christophe
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 maybe
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
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 answer to, so
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
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
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 ;.
Bye,
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
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
languages because it's
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 answer to, so
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
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
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 time
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
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
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
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 with
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
On 06/05/2012 08:42 PM, Artur Skawina wrote:
foreach (e; pointer_to_range) currently fails with:
Error: foreach: Range* is not an aggregate type
It can be worked around with
struct RangePtr(R) {
R* ptr;
alias ptr this;
@property front()() { return ptr.front; }
On Tuesday, 5 June 2012 at 18:46:51 UTC, Timon Gehr wrote:
On 06/05/2012 08:42 PM, Artur Skawina wrote:
foreach (e; pointer_to_range) currently fails with:
Error: foreach: Range* is not an aggregate type
It can be worked around with...
Why not: foreach(e; *pointer_to_range)
Seems like
On 06/05/12 21:25, Peter Alexander wrote:
On Tuesday, 5 June 2012 at 18:46:51 UTC, Timon Gehr wrote:
On 06/05/2012 08:42 PM, Artur Skawina wrote:
foreach (e; pointer_to_range) currently fails with:
Error: foreach: Range* is not an aggregate type
It can be worked around with...
Why
On Tue, 05 Jun 2012 20:46:51 +0200, Timon Gehr timon.g...@gmx.ch wrote:
It should be dropped. A pointer to range is a perfectly fine range.
Sure..? I couldn't get it to work either:
struct R {
string test = aoeu;
@property front() { return test[0]; }
@property bool empty() {
On 06/05/12 22:23, simendsjo wrote:
On Tue, 05 Jun 2012 20:46:51 +0200, Timon Gehr timon.g...@gmx.ch wrote:
It should be dropped. A pointer to range is a perfectly fine range.
Sure..? I couldn't get it to work either:
struct R {
string test = aoeu;
@property front() { return
On Tue, 05 Jun 2012 22:38:22 +0200, Artur Skawina art.08...@gmail.com
wrote:
On 06/05/12 22:23, simendsjo wrote:
On Tue, 05 Jun 2012 20:46:51 +0200, Timon Gehr timon.g...@gmx.ch
wrote:
It should be dropped. A pointer to range is a perfectly fine range.
Sure..? I couldn't get it to
On 06/05/12 22:41, simendsjo wrote:
On Tue, 05 Jun 2012 22:38:22 +0200, Artur Skawina art.08...@gmail.com wrote:
On 06/05/12 22:23, simendsjo wrote:
On Tue, 05 Jun 2012 20:46:51 +0200, Timon Gehr timon.g...@gmx.ch wrote:
It should be dropped. A pointer to range is a perfectly fine range.
On Wed, 2012-04-11 at 18:32 +0200, Jakob Ovrum wrote:
[...]
Ranges are iterated in-place. You can't mutate a const range,
hence you cannot advance it by one (`popFront`), which is
required by the lowering of foreach using the range interface.
[...]
I think I am still trying to recover from
On 04/16/2012 01:20 PM, Russel Winder wrote:
On Wed, 2012-04-11 at 18:32 +0200, Jakob Ovrum wrote:
[...]
Ranges are iterated in-place. You can't mutate a const range,
hence you cannot advance it by one (`popFront`), which is
required by the lowering of foreach using the range interface.
[...]
On Mon, 2012-04-16 at 14:58 +0200, Timon Gehr wrote:
[...]
Have you filed a bug report against Phobos for this?
Not as yet, after lunch 'twill be done.
--
Russel.
=
Dr Russel Winder t: +44 20 7585 2200 voip:
On 2012-04-13 06:50, Matt Peterson wrote:
On Thursday, 12 April 2012 at 06:46:53 UTC, Jacob Carlborg wrote:
I'm pretty sure that the JSON output can _never_ be enough for what we
want to do.
I agree with that, nothing will quite be the same as a full
compiler-as-a-library (CAAL?). But in the
* Jacob Carlborg d...@me.com [2012-04-13 08:40:39 +0200]:
On 2012-04-13 06:50, Matt Peterson wrote:
I agree with that, nothing will quite be the same as a full
compiler-as-a-library (CAAL?). But in the meantime, there is a working
compiler now, and isn't it better to get some kind of IDE-like
On 2012-04-13 11:28, James Miller wrote:
I think he means that while there isn't a suitable CaaL, there are
working compilers that can be improved to supply enough information to
atleast start on IDE integration, even if it isn't as robust or
efficient as an actual library.
From what I can
On 2012-04-12 03:31, Matt Peterson wrote:
On Tuesday, 10 April 2012 at 02:24:31 UTC, Andrei Alexandrescu wrote:
Would the JSON compiler output help?
I made a pull request a while ago that gives a lot more JSON output
(https://github.com/D-Programming-Language/dmd/pull/813). I'm willing to
try
On 2012-04-12 03:12, Ary Manzana wrote:
Yes. I'm still thinking how could it be done but I have no idea at all
how to do it. I can't figure out what that API would look like.
Yeah, designing API's are hard. I'm starting to think that a completely
new compiler (or frontend) built for this
On 04/11/2012 06:08 PM, Russel Winder wrote:
Doing something along the lines of:
const a = array ( filter! ... ) ;
foreach ( i ; a ) { ... }
works fine. Question 1 though is why I can't use immutable here, why I
have to use const.
'array' is not pure for some reason. This
On Thu, 12 Apr 2012 13:44:36 -0400, Timon Gehr timon.g...@gmx.ch wrote:
On 04/11/2012 06:08 PM, Russel Winder wrote:
Doing something along the lines of:
const a = array ( filter! ... ) ;
foreach ( i ; a ) { ... }
works fine. Question 1 though is why I can't use immutable
On 04/12/2012 08:08 PM, Steven Schveighoffer wrote:
On Thu, 12 Apr 2012 13:44:36 -0400, Timon Gehr timon.g...@gmx.ch wrote:
On 04/11/2012 06:08 PM, Russel Winder wrote:
Doing something along the lines of:
const a = array ( filter! ... ) ;
foreach ( i ; a ) { ... }
works fine. Question 1
On Thursday, April 12, 2012 19:44:36 Timon Gehr wrote:
On 04/11/2012 06:08 PM, Russel Winder wrote:
Doing something along the lines of:
const a = array ( filter! ... ) ;
foreach ( i ; a ) { ... }
works fine. Question 1 though is why I can't use immutable here, why I
have to
On Thursday, 12 April 2012 at 06:46:53 UTC, Jacob Carlborg wrote:
I'm pretty sure that the JSON output can _never_ be enough for
what we want to do.
I agree with that, nothing will quite be the same as a full
compiler-as-a-library (CAAL?). But in the meantime, there is a
working compiler
On 2012-04-11 04:50, Ary Manzana wrote:
Yes. In fact, JDT has a built-in Java compiler in their implementation.
Maybe it was easier to do it for them because the Java spec is easier
and doesn't fluctuate that much as the D spec. And JDT used that
compiler all over the place for getting all
On Wed, 11 Apr 2012 18:08:14 +0200, Russel Winder rus...@winder.org.uk
wrote:
Doing something along the lines of:
const a = array ( filter! ... ) ;
foreach ( i ; a ) { ... }
works fine. Question 1 though is why I can't use immutable here, why I
have to use const. Question
On Wednesday, 11 April 2012 at 16:08:25 UTC, Russel Winder wrote:
Doing something along the lines of:
const a = array ( filter! ... ) ;
foreach ( i ; a ) { ... }
works fine. Question 1 though is why I can't use immutable
here, why I
have to use const.
An array/slice has
On Wednesday, 11 April 2012 at 16:33:42 UTC, Simen Kjaeraas wrote:
On Wed, 11 Apr 2012 18:08:14 +0200, Russel Winder
rus...@winder.org.uk wrote:
Doing something along the lines of:
const a = array ( filter! ... ) ;
foreach ( i ; a ) { ... }
works fine. Question 1 though is
Jakob Ovrum:
Value types with no indirection are implicitly convertible to
immutable.
---
void main()
{
int a = 2;
immutable int b = a;
}
---
And far more, even with immutable reference types, in this
program 'a' has to be immutable, no just const:
int[]
On Wednesday, 11 April 2012 at 17:00:43 UTC, bearophile wrote:
Jakob Ovrum:
Value types with no indirection are implicitly convertible to
immutable.
---
void main()
{
int a = 2;
immutable int b = a;
}
---
And far more, even with immutable reference types, in this
On 4/11/12 4:27 PM, Jacob Carlborg wrote:
On 2012-04-11 04:50, Ary Manzana wrote:
Yes. In fact, JDT has a built-in Java compiler in their implementation.
Maybe it was easier to do it for them because the Java spec is easier
and doesn't fluctuate that much as the D spec. And JDT used that
On Tuesday, 10 April 2012 at 02:24:31 UTC, Andrei Alexandrescu
wrote:
Would the JSON compiler output help?
I made a pull request a while ago that gives a lot more JSON
output (https://github.com/D-Programming-Language/dmd/pull/813).
I'm willing to try to improve it to better meet the needs
On 2012-04-10 04:21, Ary Manzana wrote:
In fact, I think Walter and company should stop working on the current
DMD codebase and start all over again. The code, as I see it, is a big
mess. Now that the spec is more or less clear and not many new
features are added, I think this is the time to do
On 2012-04-10 04:47, Brad Anderson wrote:
It's already been started. SDC: https://github.com/bhelyer/SDC
But has it been built to be usable as a library?
--
/Jacob Carlborg
On 2012-04-10 04:24, Andrei Alexandrescu wrote:
On 4/9/12 9:21 PM, Ary Manzana wrote:
Yes, D definitely needs that. The Eclipse plugin could just use bindings
to the D compiler API with JNI.
Would the JSON compiler output help?
Andrei
No, it's no way near sufficient for what Descent can do
On 4/9/12, Kevin Cox kevincox...@gmail.com wrote:
The
reason I aski is because if you have a return statement inside a foreach it
returns from the outside function not the closure.
I don't like this subtle thing. For example let's say a newbie were to
implement a function called isDirEmpty.
On 10.04.2012 13:33, Andrej Mitrovic wrote:
On 4/9/12, Kevin Coxkevincox...@gmail.com wrote:
The
reason I aski is because if you have a return statement inside a foreach it
returns from the outside function not the closure.
I don't like this subtle thing. For example let's say a newbie were
On 4/10/12, Dmitry Olshansky dmitry.o...@gmail.com wrote:
Wake up! dirEntries produce a lazy _range_ and it's not opApply
Sorry? Change DirIterator in std.file to this:
http://pastebin.com/DHvXuFeH
test.d:
import std.file;
bool isEmptyDir(string path)
{
foreach (string name;
On 04/10/2012 12:06 PM, Andrej Mitrovic wrote:
On 4/10/12, Dmitry Olshanskydmitry.o...@gmail.com wrote:
Wake up! dirEntries produce a lazy _range_ and it's not opApply
Sorry? Change DirIterator in std.file to this:
http://pastebin.com/DHvXuFeH
You are doing it wrong.
Use:
if(auto r=dg(s))
On 04/10/2012 11:33 AM, Andrej Mitrovic wrote:
On 4/9/12, Kevin Coxkevincox...@gmail.com wrote:
The
reason I aski is because if you have a return statement inside a foreach it
returns from the outside function not the closure.
I don't like this subtle thing. For example let's say a newbie
On 04/10/2012 12:50 PM, Timon Gehr wrote:
On 04/10/2012 12:47 PM, Timon Gehr wrote:
On 04/10/2012 12:06 PM, Andrej Mitrovic wrote:
On 4/10/12, Dmitry Olshanskydmitry.o...@gmail.com wrote:
Wake up! dirEntries produce a lazy _range_ and it's not opApply
Sorry? Change DirIterator in std.file
On 04/10/2012 12:47 PM, Timon Gehr wrote:
On 04/10/2012 12:06 PM, Andrej Mitrovic wrote:
On 4/10/12, Dmitry Olshanskydmitry.o...@gmail.com wrote:
Wake up! dirEntries produce a lazy _range_ and it's not opApply
Sorry? Change DirIterator in std.file to this:
http://pastebin.com/DHvXuFeH
You
On 10.04.2012 14:06, Andrej Mitrovic wrote:
On 4/10/12, Dmitry Olshanskydmitry.o...@gmail.com wrote:
Wake up! dirEntries produce a lazy _range_ and it's not opApply
Sorry? Change DirIterator in std.file to this:
http://pastebin.com/DHvXuFeH
Yeah recent change allowed to use straight alias
On 10.04.2012 14:50, Timon Gehr wrote:
On 04/10/2012 12:47 PM, Timon Gehr wrote:
On 04/10/2012 12:06 PM, Andrej Mitrovic wrote:
On 4/10/12, Dmitry Olshanskydmitry.o...@gmail.com wrote:
Wake up! dirEntries produce a lazy _range_ and it's not opApply
Sorry? Change DirIterator in std.file to
On 04/10/2012 12:54 PM, Dmitry Olshansky wrote:
On 10.04.2012 14:50, Timon Gehr wrote:
On 04/10/2012 12:47 PM, Timon Gehr wrote:
On 04/10/2012 12:06 PM, Andrej Mitrovic wrote:
On 4/10/12, Dmitry Olshanskydmitry.o...@gmail.com wrote:
Wake up! dirEntries produce a lazy _range_ and it's not
501 - 600 of 811 matches
Mail list logo
