| 15:35 | <Timo Tijhof> | I noticed an interoperability issue between Firefox and Chrome when it comes to Array sort(), in particular, the presence of an undefined/NaN can not only affect the position of the NaN but the order of all other items which seems problematic? Minimal example at https://phabricator.wikimedia.org/P63711 |
| 15:36 | <Timo Tijhof> | Firefox: 0, 1, undefined, -10, -9Chrome: -10, -9, 0, 1, undefined |
| 15:49 | <eemeli> | Timo Tijhof: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/sort#sorting_with_non-well-formed_comparator |
| 15:52 | <Timo Tijhof> | eemeli: Is there no apetite for tightening the spec around this? I get the argument for mathematical purity, but I don't see the benefit in allowing it to remain as unspecified/undefined behaviour. We've already crossed the bridge of stable sorting for identical values based on input. Standardising behaviour around NaN seems like a natural next step. |
| 16:00 | <bakkot> | It's not the behavior around NaN, it's the behavior around inconsistent comparators |
| 16:00 | <eemeli> | My guess would be that it would be difficult to define the sorting behaviour more strictly without introducing performance penalties for some implementations. |
| 16:01 | <bakkot> | there might someday be appetite to fully specify behavior even in the presence of inconsistent comparators, but that would require a particular sorting algorithm (or at least more specific than currently), which would prevent implementations with experimenting with alternative sorting algorithms, which is a very nice thing for them to be able to do |
| 16:13 | <whosy> | Is there anything we can do to make it easier to write compliant comparators for the more frequent and trivial cases, such as the example above? |
| 16:22 | <bakkot> | we could provide a sortBy method that takes a function from list members to numbers and then sorts according to the result, and if we specified where NaN goes in such a list (or that getting NaN throws, my preference) that would address this case |
| 16:22 | <bakkot> | I have wanted this for a while but not had time to pursue it |
| 16:22 | <bakkot> | also we could provide a built-in comparator for the common case of sorting a list of numbers, though it wouldn't help in the given example |
| 16:25 | <ljharb> | (a, b) => (a.index - b.index) || 0 seems like it'd make it consistent? |
| 20:26 | <whosy> | If I might ask a question to such experienced people, as someone working on their first proposal: How opinionated should a proposal be at stage 0? Should it try to be loose and open for many ideas and suggestions from others, or should it try to be more rigorous and concrete already at this stage? Or am I thinking too much of the solution when I should really focus more effort on the initial problem at this point? |
| 20:33 | <Timo Tijhof> | Hm.. no, result remains different in Chrome/Firefox in the same way with this change applied. I also thought at first it was the NaN messing it up. It does seem to play a role, but it's not strictly the presence of NaN. From what I can tell, NaN is for all intends and purposes already treated by all implementations as 0. I haven't checked engine sources, but observationally, this appears to be true. If it was that simple, I would imagine a spec change would be less controversial as well to make it so, but from what I can tell, that has effectively been done already (not sure how recent, if recent). |
| 20:36 | <ljharb> | at stage 0 and 1, a proposal is really just a problem (altho it's nice to have a suggested solution). it's tough to be too opinionated about a problem, besides "i actively don't want this part of the problem solved". so if you're that deep into a solution i'd say it might be too early to do so :-) |
| 20:38 | <Chris de Almeida> | If I might ask a question to such experienced people, as someone working on their first proposal: |
| 20:41 | <whosy> | I appreciate the feedback. The proposal is not exactly complex or controversial and exists in pretty much every other language (methods for generating random numbers, outside just a [0-1) float). I think I am just battling my perfectionist side here, and am trying to make things far too complete for where I am in the proposal. |
| 20:44 | <bakkot> |
a, b, c such thata = b and b = c but not a = c when b is the value without an index (because in that case the comparison function will return NaN when comparing b to either a or c). this makes it not a consistent comparator and the spec doesn't mandate any particular order here. |
| 20:44 | <bakkot> | it is hard to specify exactly what the order should be when a comparator is not consistent without mandating engines either do a bunch of additional work or implement precisely the same algorithm, neither of which is desirable |
| 20:45 | <bakkot> | I appreciate the feedback. The proposal is not exactly complex or controversial and exists in pretty much every other language (methods for generating random numbers, outside just a [0-1) float). |
| 20:47 | <bakkot> | don't worry about exactly what functions to include or try to specify them or anything like that at this stage, just document "this is a common/reasonable thing to want which is at least moderately annoying to do", i.e., establish that it is a problem worth solving |
| 20:47 | <Michael Ficarra> | If I might ask a question to such experienced people, as someone working on their first proposal: How opinionated should a proposal be at stage 0? Should it try to be loose and open for many ideas and suggestions from others, or should it try to be more rigorous and concrete already at this stage? Or am I thinking too much of the solution when I should really focus more effort on the initial problem at this point? |