| 03:01 | <devsnek> | should we remove the last sentence from this? https://tc39.es/ecma262/#sec-ecmascript-language-types-number-type |
| 03:01 | <devsnek> | you can observe different NaN values using pure ecmascript |
| 03:03 | <Bakkot> | devsnek that would probably require getting into https://github.com/tc39/ecma262/pull/758 again |
| 03:03 | <Bakkot> | which no one has expressed much appetite for |
| 03:03 | <devsnek> | i'm not suggesting we change anything normativ |
| 03:03 | <devsnek> | ely |
| 03:03 | <Bakkot> | or, maybe we will get back to it actually |
| 03:04 | <devsnek> | but like factually, you can observe nan bit patterns using arraybuffer views |
| 03:04 | <devsnek> | that sentence is from like es1 or something |
| 03:04 | <Bakkot> | it is implementation-dependent whether or not that is the case |
| 03:04 | <Bakkot> | is the problem |
| 03:05 | <devsnek> | i'm saying we should remove the thing that says you can't, not that we should add something that says you can |
| 03:07 | <shu> | there's a note about observing bit patterns via AB/SAB |
| 03:08 | <shu> | there's a bit of a conceit there about "NaN as a Number value" and "NaN as a bit pattern after storing in a buffer" |
| 03:08 | <shu> | the last sentence seems to be about the former |
| 03:10 | <devsnek> | i can see the path of logic there |
| 03:10 | <devsnek> | i don't necessarily agree with it |
| 03:13 | <shu> | in general, i think a sentence calling of "this thing is indistinguishable except with these enumerated APIs + extra-language utilities" is valuable and would rather keep it in |
| 03:13 | <shu> | though i agree that it might need to be tightened up to actually reflect reality |
| 03:13 | <shu> | s/calling of/calling out |
| 03:16 | <devsnek> | future proposal: nan literals and nan reflection |
| 03:20 | <shu> | BigInt.fromAnyAsUintptr |
| 03:20 | <shu> | it's one of the things i've always wanted |
| 03:21 | <shu> | now that we have bigint we can even make it future proof for 64+ bit archs |
| 03:21 | <rkirsling> | anybody have experience with figuring out what in a given ICU/CLDR release is changing observed behavior? |
| 03:23 | <rkirsling> | seems like `Intl.NumberFormat('es').format(1234.567)` changed from `1.234,567` to `1234,567` in ICU 64 (or CLDR 35) but the resolvedOptions are the same either way |
| 14:25 | <bradleymeck> | I feel like we should go back to proposing compositeKey |
| 14:26 | <bradleymeck> | i've let it stall due to normalization, but thats now dead due to bikeshed |