| 14:32 | <jmdyck> | Bakkot: In https://github.com/tc39/ecma262/pull/2013, the Travis build is failing because ecmarkup is complaining about the lines |
| 14:32 | <jmdyck> | <pre><code class="javascript">constructor(...args) { super(...args); }</code></pre> |
| 14:32 | <jmdyck> | and |
| 14:32 | <jmdyck> | <pre><code class="javascript">constructor() {}</code></pre> |
| 14:33 | <jmdyck> | But those lines exist in current master. (I've just changed lines around them.) |
| 14:34 | <jmdyck> | I've looked at the ecmarkup code, and I can't figure out why it complains for my PR but not for master. |
| 14:35 | <devsnek> | jmdyck: i like your proposal |
| 14:35 | <devsnek> | pr |
| 14:35 | <jmdyck> | tx |
| 14:36 | <devsnek> | ok real question time, should we use AggregateError for handling the array of errors from parsing :P |
| 14:38 | <jmdyck> | from the Promise.any proposal |
| 14:47 | <devsnek> | sort of joking, but it might encourage implementations to actually support reporting multiple early errors |
| 17:42 | <alystair> | why aren't 'true' and 'false' strings truthy/falsy? |
| 17:44 | <bradleymeck> | alystair: history, can't change now |
| 17:45 | <jackworks> | That's a super footgun |
| 17:50 | <ljharb> | it'd be super weird that `str + 'e'` might suddenly make it falsy |
| 17:50 | <ljharb> | i don't think it's a footgun in the language; i think it's perhaps one in HTML, and server frameworks like express, and CLI arg parsers |
| 18:11 | <TabAtkins> | I suspect jackworks is saying that "false" being falsey would be a footgun, not the *lack* of said feature. ^_^ |
| 18:11 | <TabAtkins> | And yeah, YAML shows pretty clearly the problem with implicitly mixing the string value space with other types |
| 18:17 | <ljharb> | ohhh right, in that case sorry jackworks, i agree :-) |
| 18:26 | <devsnek> | booleans should have been symbols. in this essay I will anger everyone for no reason |
| 19:40 | <alystair> | hehe |
| 19:40 | <alystair> | thanks all |
| 21:15 | <TabAtkins> | `Symbol.t` and `Symbol.nil`, ship it |
| 21:35 | <Sirisian|Work> | littledan, In the operator overloading spec why is there a RightOperatorDefinitions? I haven't thought too hard about this, but JS has no binary operators in the form "a operator b" that can't be written a.operator(b) right? |
| 21:35 | <littledan> | sorry, I don't understand the question |
| 21:35 | <littledan> | the idea is that you could overload stuff like number * vector, if you define a vector class |
| 21:35 | <littledan> | (which is one of the motivating examples in the post) |
| 21:36 | <littledan> | can you just use methods instead? sure, if you don't care about that particular ergonomics thing |
| 21:36 | <Sirisian|Work> | Wouldn't Number have an operator set and then just have the Vector operator in it's LeftOperatorDefinitions? |
| 21:48 | <Sirisian|Work> | Just so I understand things. Every class type (and Number, BigInt, etc) would have an Operator Set with a unique OperatorCounter identifier. So if you define N classes (counting Number, BigInt, etc) in theory you'd have a NxN matrix. (Probably stored in a different data structure in practice). What I'm wondering is based on JS's current types couldn't this just store the lower or upper triangle of the matrix and thus just |
| 21:48 | <Sirisian|Work> | LeftOperatorDefinitions. |
| 21:48 | <Sirisian|Work> | er JS's current operators* |
| 22:11 | <TabAtkins> | Sirisian|Work: An important bit is that the set of operations is not meant to be adjustable after-the-fact, I think. So the Vector author can't modify Number's overrides. |
| 22:41 | <Sirisian|Work> | That makes sense if it's to control the not editing aspect. I'll read the spec closer. |