A problem with generators

[bearophile]

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