# Builtin Ord / Compare method for primitives

**URL:** https://es.discourse.group/t/builtin-ord-compare-method-for-primitives/724
**Category:** 💡 Ideas
**Created:** [April 4, 2021, 2:08pm UTC](https://es.discourse.group/t/builtin-ord-compare-method-for-primitives/724 "2021-04-04T14:08:28Z")
**Posts on this page:** 1
**Showing post:** 20

<div class="post-metadata">

### Author: ![theScottyJam](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/thescottyjam/32/616_2.png) [@theScottyJam](https://es.discourse.group/u/theScottyJam)
#### Post date: [April 5, 2021, 7:09pm UTC](https://es.discourse.group/t/builtin-ord-compare-method-for-primitives/724/20 "2021-04-05T19:09:46Z")

</div>

I won't deny that there are times when +0 and -0 behave differently, and it can be useful to distinguish the two values. I've had to do so before. But, I don't necessarily see that as a reason for wanting to sort +0 higher than -0. If we went back to a hypothetical priority queue example, and assume we use this Number.compare() algorithm under the hood, then we would get the following odd outcome:

```javascript
queue = new PriorityQueue()

queue.add('a', { priority: -0 })
queue.add('b', { priority: +0 })
queue.front() // 'b' is at the front, even though 'a' was added first, because -0 is not the same priority as +0.

```

Most likely, if this priority queue is receiving -0 and +0 as parameters, this is just due to an artifact of how the priorities got calculated. I wouldn't expect to have to normalize the sign of my zeros before giving this queue my priority to make it treat +0 and -0 the same, nor do I see a practical reason for giving +0 higher priority over -0.

If I happened to give the priorityQueue a priority of "some string" or `{ myKey: 'myValue' } or NaN, I would expect it to throw an error - I just gave it a bad parameter that can't be sorted on. I, likewise, don't see a practical reason for NaN to have higher priority than all other numbers.

If you're trying to sort an array using the sort function `(a, b) => a - b`, and your array contains strings, objects, or NaN, then a programmer error has already happened before that line has executed, and in an ideal world, the sort function would throw, but because Javascript is lenient, it'll attempt a sort anyways. Instead of making NaN sortable, the real solution would be to check for NaN beforehand and throw if it's found. i.e.

```javascript
const items = [4, NaN, 3, NaN, 2, NaN, 1, NaN]
if (items.some(x => isNaN(x) || typeof x !== 'number')) throw new Error('Bad parameter!')
return items.sort((a, b) => a - b)

```

If we did have a Number. compare() function, my preference would be that it threw if it received parameters such as a string, object, or NaN.

There might be a reason for wanting these two properties in a numeric sorting algorithm, but, from what I can tell, most of the time they aren't desired, and I honestly can't think of a concrete use case where they would be desirable properties.

---

_[View the full topic](https://es.discourse.group/t/builtin-ord-compare-method-for-primitives/724)._