3 ms·

since there's no such things as iterators in this language, it's the responsibility of the programmer of the for_expansion to make the keywords do what makes se

since there's no such things as iterators in this language, it's the responsibility of the programmer of the for_expansion to make the keywords do what makes sense in the context of iterating over the struct in a for loop. I don't understand why you think it's a bad idea. you write a struct for your data container, you write a for_expansion that allows for it to be iterated over in a for loop, and you optionally define what break, continue, and remove do in the context of the for_expansion you wrote. it's not as open to unexpected craziness as operator overloading can be because these keywords only work in the context of a for loop, and you are defining how a for loop is handled for your struct... where's the issue?

jdmichal 5y ago
The issue is that those keywords are expected to work a particular way, just like operators. Just like the operator + is expected to do some sort of addition operation, the keyword `break` is expected to do some sort of loop exit operation. The ability to reprogram the break operator to do anything else isn't useful for anything other than breaking expectations. And having to program the same break mechanics into every single iterable type rather than simply implementing an `Iterator` interface which then has those operators implemented seems less optimal. Which is why I said, it seems like the only advantage is the ability to break expectations. Which is arguably, realistically a disadvantage.