I should have been clearer in my original message; I'll avoid mentioning Ruby directly, again, as it misdirects conversation.
Though I have no strong opinion on block-lambdas in javascript, I will try to restate my original position, for clarity: Block lambdas, as currently described in the proposal and in the community, have 'forEach' and similar as driving examples; I believe that a typical programmer would expect break or continue to directly affect that loop, and that that behaviour may be desirable. Brendan Eich wrote: > "Intuitive" depends on intuition, which is not well-defined. True, but I do believe in intuition without the bias of a source language. I understand that intuition can vary, so I might be aiming for 'average practitioner's intuition' or such. > Do you mean a Rubyist might expect different behavior for break? I believe that the typical programmer, given the briefest exposure to block lambdas, would believe that 'continue' would behave the same way for a block-lambda-based loop as it does for any other loop. > Wait, why do you think break and continue without label operands > do anything other than break from the nearest enclosing loop What I meant was that, in the typical examples, 'forEach' is the nearest enclosing loop, and continue and break apparently bypass it. > The Array.prototype.forEach method's internal implementation is > its business, and a break instead of the return would be a static > error in this example. It would not be a dynamic throw-like > construct that is caught by forEach's implementation. Indeed, the way break would need to work could be a show-stopper for my proposed alteration, but I was trying to avoid implementation detail. My intent was to raise the divergence from (in my opinion) intuitive behaviour in the case of block-lambda-based loops. Regards, Grant Husbands. _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
