| 08:52 | <sideshowbarker> | comments welcome at https://github.com/mdn/content/issues/12908 or here
|
| 09:00 | <Andreu Botella> | isn't that expected? |
| 09:00 | <Andreu Botella> | returning skips the rest of the callback, but not subsequent iterations, because they're different runs of the callback |
| 09:01 | <Andreu Botella> | the issue only comes when porting code that uses a for loop to code using forEach |
| 09:08 | <annevk> | I suspect what they're asking for is for the article to point out you cannot break out of the loop. |
| 12:18 | <Ashley Claymore> | There is already a section for this that says: "There is no way to stop or break a forEach() loop other than by throwing an exception" https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/forEach#sect2 |
| 12:18 | <Ashley Claymore> | maybe it could be even more explicit? |
| 12:46 | <annevk> | Good point, dunno then. |
| 13:08 | <sideshowbarker> | OK, thanks all — yeah, seems like the OP just had the expectation that the return would break out of the forEach(). So I guess I’ll add something to the “There is no way to stop or break a forEach() loop other than by throwing an exception” note explicitly saying that a return will not break out of the forEach() but will instead just return from the current call to the callback function, and the continue the loop. |
| 14:17 | <Jessidhia> | the easy workaround is to use .every() and return true to continue and return false to break |
| 14:17 | <Jessidhia> | but feels weird since it’s not a function supposed to be side effectful |
| 16:19 | <jschoi> | Check for my own sanity: The fact that https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Operator_Precedence puts ? : on a precedence level tighter than = and yield is incorrect, right? |
| 16:19 | <jschoi> | Because https://tc39.es/ecma262/#prod-AssignmentExpression says AssignmentExpression : ConditionalExpression and ConditionalExpression : ShortCircuitExpression ? AssignmentExpression : AssignmentExpression. |
| 16:20 | <jschoi> | (I already fixed one error in this table with ?? last year, so I’m not surprised there’s still other errors.) |
| 16:21 | <bakkot> | it's not really meaningful to talk about precedence for a ternary as a whole |
| 16:21 | <bakkot> | but yield a ? b : c is yield (a ? b : c) and x = a ? b : c is x = (a ? b : c) |
| 16:22 | <bakkot> | so to the extent there is precedence at all, I think it's correct to say that yield binds less tightly than ? : |
| 16:26 | <jschoi> | Point taken. This is mostly a result of the weird interactions between ternary and unary/binary operators… |
| 16:32 | <bakkot> | well, and assignment |
| 16:32 | <bakkot> | yield is less weird because yield a is always yield a in any of the three positions |
| 16:33 | <bakkot> | but assignment is weird because a = b ? c : d parses as assignment-containing-ternary whereas a ? b : c = d parses as ternary-containing-assignment |
| 16:33 | <jschoi> | Yeah, and assignment’s weird asymmetry too. |
| 16:34 | <jschoi> | Come to think of it, I still want to add => to this table, since it is pretty much analogous to =… |
| 16:35 | <jschoi> | = and => are both more like…prefix unary operators on their RHS. (With possible evaluation on any default expressions in their LHS afterwards.) |
| 16:38 | <jschoi> | (All of this weirdness is also why we are banning mixing any of these within |> pipe expressions without parentheses.) |
| 17:44 | <TabAtkins> | Still think that forEach should be extended to pass the callback a fourth argument that's a "halt token", which stops execution if you return it. Then the four callback arguments will be Element, Index, Collection, Halt, or EICH |
| 18:25 | <Domenic> | Or just don't use forEach... for-of is just way better IMO. |
| 18:28 | <Domenic> | https://ericlippert.com/2009/05/18/foreach-vs-foreach/ |
| 18:41 | <jschoi> | Yeah, but Tab has a point: we would get an EICH abbreviation in the language. The next step would be to somehow add BRENDAN somewhere. |
| 18:43 | <TabAtkins> | right, that's the whole point. not worth doing it otherwise |
| 19:29 | <jschoi> | Given that 1 ? x = 2 : 3 groups as 1 ? (x = 2) : 3 and that 1 ? x => 2 : 3 groups as 1 ? (x => 2) : 3, is it fair to say that ? : is acting “looser” than = or => here? |
| 19:33 | <bakkot> | I wouldn't describe it that way personally, since that it is also true that a => b ? c : d groups as a => (b ? c : d) |
| 19:34 | <bakkot> | you can't really say one is strictly looser than the other |
| 19:34 | <jschoi> | Yeah. The whole concept of “precedence” breaks down at this level…I’m not sure how to explain where |> (which has similar “precedence” as these) fits in with them in laypersons’ terms (let alone explaining how yield, =, =>, and ? : interact in such terms). |
| 19:34 | <bakkot> | I don't think laypeople think in terms of precedence |
| 19:35 | <bakkot> | just give examples of how various things would be grouped like we've been doing here |
| 19:35 | <bakkot> | it's by far the clearest way to explain |
| 19:37 | <jschoi> | Well, one thing I know is that laypeople have been referring to that MDN precedence table, and that the table has been confusing laypeople about ? :, =, and yield. |
| 19:37 | <jschoi> | So I wonder if we shouldn’t put ? :, =, yield, and => all on one “precedence level” and just say, “These don’t really have more or less ’precedence’ than one another; they have special rules; see these examples.” |
| 20:45 | <jmdyck> | jschoi: Re question in Delegates room: you can say "the first AssignmentExpression" and "the second AssignmentExpression" |
| 20:48 | <jmdyck> | See e.g. https://tc39.es/ecma262/#sec-runtime-semantics-forloopevaluation where it has to differentiate between the various |Expression|s |
| 21:48 | <jschoi> | Sorry, wrong room! |