dsimcha:
> The **BIG** advantage of the status quo, where the loop body is a delegate
> instead
> of being "magic", is that it enables lots of hackish things to be done, like
> running different iterations of the loop in different threads.
That's a defect, not a quality ;-)
Something like this:
yield(int) foo() { yield 5; }
Has advantages:
- It's much simpler to remember, while I need to look in code snippets every
time I want to write an opApply
- It's shorter to write and to read, so you need less time to write code, you
put less bugs in the code, and your program gets smaller. It saves several
lines of code. It's easy to see if it's correct.
- It's simpler to learn, python and C# programmers need almost zero time to
learn it, and other programmers surely will find it simpler than the opAssign.
And If you want to do hacks there's the other syntax, based on range iteration
methods.
As you say, the good thing of opApply is that it contains no magic, the syntax
can almost be mapped (if you know D very well) to the assembly code the
compiler will generate. But there's not enough sugar there.
Anyway, D2 is finalized, so I don't think yield will be added soon. It's OK.
But I think opApply is a hack that I don't like to see in D2. Go language shows
that it's better to not have a feature than having a bad one, even if it's a
very important feature like exceptions, classes, etc, because new features can
be added later, while it's harder to remove them.
Bye,
bearophile
