On 10.04.2012 13:33, Andrej Mitrovic wrote:
On 4/9/12, Kevin Cox<[email protected]> 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". The first hint is to try to
walk the directory iteratively and return as soon as there's a match,
e.g.:
bool isEmptyDir(string path)
{
foreach (_; dirEntries(path, SpanMode.shallow))
return false;
return true;
}
isEmptyDir never returns false. All that false statement does is break
out of the foreach loop.
Wake up! dirEntries produce a lazy _range_ and it's not opApply &
closures. And you were the one to come up with this cool
parallel(dirEntries(...)) thing back when it was introduced.
Anyway that "return" false would have been translated to some
"black-magic" jump.
Of course the right way to implement this is:
bool isEmptyDir(string path)
{
return dirEntries(path, SpanMode.shallow).empty;
}
But still, the first version is extremely subtle. The semantics of
that code completely change based on whether dirEntries is an array, a
range, or an opApply.
array vs range is the same here. opApply is the weirdo.
--
Dmitry Olshansky
