| 03:05 | <Domenic> | Excited to see progress on iterator helpers |
| 22:34 | <sideshowbarker> | https://github.com/mdn/content/issues/12914 is an open issue about some of the MDN JavaScript docs that we could use some insight from others on — specifically it’s about the https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Operator_Precedence page, for which we sometimes get requests to include precedence information about things that aren’t actually operators. One thought I had was that maybe we could retitle the page “Operator precedence and order of evaluation” , though I’m not sure even that would be enough to cover the non-operator cases that people have opened issues about. |
| 22:44 | <jschoi> | I’ve actually touched on this in that repository’s issues before, too, in https://github.com/mdn/content/issues/5365. I think we’ve discussed it a couple times here too; I remember raising it. For what it’s worth, it is my opinion that => is an operator in every way that = is an operator, and it is completely appropriate to include => in a “table of operators” if = is in there too. There’s hardly any difference of worth between them. |
| 23:03 | <sideshowbarker> | jschoi: Thanks yeah — IMHO we’d be better off if we removed Anyway, my perspective on this is that every good intro-to-this-programming-language book I’ve ever read has a section for operator precedence that only includes actual operators — and then some separate discussion about order of evaluation. I don’t think the MDN JavaScript docs should be less precise or less rigorous about details like this than a well-written book would be. So that’s why I think, if we’re going to include things on that page that are not strictly operators according to the rules of the language, then we minimally should at least re-title the page — and beyond that, make it very clear which things are strictly operators and which are not. |
| 23:08 | <jschoi> | @sideshowbarker: Yeah, I can certainly sympathize with the desire for rigor on MDN. And it certainly would be consistent to exclude both = and => from being operators. I don’t know if there’s any rigorous-but-still-useful definition of “operator” that would exclude =, though. I think that you could rigorously define a JavaScript operator as a “syntactic token(s) that create an expression but which is not a literal”, where an “expression” is a “syntax phrase that evaluates into a value at runtime”. So yield is a nullary-or-prefix operator (with side effects). + is a prefix-or-binary operator. import() probably should be called a circumflex operator (I forgot if it’s in the MDN table). And = and =>, I think, can reasonably be rigorously called operators, too. They’re certainly not literals or statements, heh. |
| 23:11 | <sideshowbarker> | I think I’m just gonna leave it up to Josh Chen to try to solve 😋 He’s been doing some great work on the JavaScript docs recently, with in general a much more informed perspective than mine anyway |
| 23:24 | <jschoi> | Sounds good. Some prior related discussion I found (sparked by the interpolate syntax of match):https://matrixlogs.bakkot.com/TC39_General/2021-12-07 https://matrixlogs.bakkot.com/TC39_General/2021-12-08 |