Consider allowing na_value = "first" and na_value = "last" in vec_order() / vec_sort()

[DavisVaughan]

I actually think sort(decreasing =, na.last = ) is the right separation of responsibilities for these arguments because you can think about them completely independently of each other.

With our direction and na_value arguments, you currently have to think about them together, i.e. na_value = "largest" puts:

• NA first if direction = "desc"
• NA last if direction = "asc"

And this always takes me a second to get right.

The vec_order() internals even remap our args to decreasing and na.last to make them independent again.

---

@hadley suggested maybe we could fix this by adding "last" and "first" as na_value options, so you could do:

• direction = "asc", na_value = "first"
• direction = "asc", na_value = "last"
• direction = "desc", na_value = "first"
• direction = "desc", na_value = "last"

And that way you can think about the args completely independently again

---

We may only want to add this to our radix ordering approach to vec_order(), i.e. we could treat it as a feature when we switch vec_order() to use vec_order_radix(), which should happen in the next big vctrs release