Not Ruby alone, and not in any chauvinist my-language-is-better sense. Smalltalk is the original inspiration for Ruby blocks, and the correspondence principle has deep roots.
"Intuitive" depends on intuition, which is not well-defined. Do you mean a Rubyist might expect different behavior for break? That is possible but JS ain't Ruby and break should not change to do something like what it does in Ruby (and we aren't defining a next equivalent for JS).
Wait, why do you think break and continue without label operands do anything other than break from the nearest enclosing loop (or switch or labeled statement if break), or continue the nearest enclosing loop? The proposal specifies this. function find_odds_in_arrays(list, // array of arrays skip) // if found, skip rest { let a = []; for (let i = 0; i < list.length; i++) { list[i].forEach { |e| if (e === skip) { continue; // continue the for loop } if (e & 1) { a.push(e); } } } return a; } function find_more_odds(list, stop) { let a = []; for (let i = 0; i < list.length; i++) { list[i].forEach { |e| if (e === stop) { break; // break from the for loop } if (e & 1) { a.push(e); } } } return a; }
What do you mean by this? The spec talks about nearest enclosing loop or relevant control structure in the source code. Are you talking about internal loops in implementations (dynamically dispatched at that) of methods that take block-lambdas as arguments? I.e. function find_first_odd(a) { a.forEach { |e, i| if (e & 1) return i; } // returns from function return -1; } 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. /be |
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss


