15:04 | <littledan> | well, cleanupSome is at Stage 2, so those need to be fixed anyway |
15:04 | <littledan> | it was taken out of the WeakRef/FinalizationRegistry proposal a while ago |
16:55 | <bakkot> | and that's something you'd want to do with syntax ((prop << 2) | prop2 , etc), not with number-taking APIs, so even that use case doesn't imply number-taking APIs ought to accept booleans |
17:55 | <TabAtkins> | yes, i was replying to "boolean to string or number" |
17:56 | <TabAtkins> | (twice now you've replied to me about the opposite direction of what i was talking about when responding to chris - you might want to read the convo a little more closely ^_^) |
17:59 | <bakkot> | sorry, I got my nouns switched in previous comment; fixed now |
17:59 | <bakkot> | didn't misread you, just misspoke |
18:00 | <TabAtkins> | ah yes, then, still agree that outside of that operator-mangling case there's really no argument for a bool to coerce to a number |
18:00 | <bakkot> | though the earlier comment, I don't see how it's the opposite direction of what you said? |
18:01 | <TabAtkins> | maybe i'd misread what Chris said in "I think "true" and "false" should be fair game for implicit conversion to boolean" |
18:01 | <TabAtkins> | i thought they were implying that converting "true" and "false" to true and false was fair game? |
18:02 | <TabAtkins> | (which i oppose) |
18:05 | <bakkot> | ok, so you meant "we can't make "false" coerce to false in future boolean-taking APIs", rather than "we can't change how "false" is handled in existing APIs", which is how I read you |
18:06 | <bakkot> | anyway yes agreed that "false" should not coerce to false in any new or future API |
18:08 | <bakkot> | incidentally, that reminds me of this excellent example of why coercing strings to booleans is a bad idea: https://github.com/tc39/proposal-intl-numberformat-v3/pull/107 |
18:09 | <bakkot> | API was being expanded to take more than two values, but people were already passing strings, and some people were passing the string "false" and (apparently) relying on that being true |
18:09 | <bakkot> | leading to this lovely bit of spec:
|
18:09 | <Chris de Almeida> | yeah that's annoying |
18:12 | <Chris de Almeida> | I walk back what I said about boolean strings being implicitly converted |
18:13 | <Chris de Almeida> | especially as it would fly in the face of my first point about existing behavior for conditions re: truthy/falsey |
19:21 | <rbuckton> | Given how long its been since I last presented The PR for the relevant changes to the The relevant change since this was last proposed for advancement from Stage 2 to Stage 3 is the addition of a new lookahead restriction at the end of the expression that would disallow any trailing binary operator or My hope is that I can propose advancement to Stage 3 at the next plenary assuming I can find willing volunteers for reviewers in advance of the meeting. |
23:00 | <davethegr8> | Did anyone happen to make a summary of what advanced from last plenary? |
23:24 | <Chris de Almeida> | Did anyone happen to make a summary of what advanced from last plenary? |
23:24 | <davethegr8> | Rob Palmer's twitter and Hemanth's blog |
23:24 | <Chris de Almeida> | https://dev.to/hemanth/updates-from-the-97th-tc39-meeting-1cnj |
23:25 | <Chris de Almeida> | https://twitter.com/robpalmer2 |