Remove the Ord impl for LanguageIdentifier / Locale

[sffc]

Currently, the auto-derived Ord impl of LanguageIdentifier sorts them by struct values, which is close to but not exactly the same as lexical order of the strings. For example, "und" is sorted at the beginning, rather than in the 'u's.

What behavior do we want? Should we keep the default Ord, or should we write a custom Ord that results in the same ordering as sorting by the string values?

Needs input from:

• @zbraniecki
• @dminor
• @Manishearth

[Manishearth]

I don't really have strong opinions, I kinda find that "und" being sorted specially is fine: it is special so it isn't surprising that it is sorted differently. If the status quo were that the derive handled und as a string then I wouldn't argue for an explicit impl that handled it specially, but given that that's already the case I don't feel the need to go to a stringy handling

[zbraniecki]

Semantically Arabic and German are not quantifiable and comparable. Their stringified serializations are. So then we can argue that und is in the same box and should be alphabetically between t and w.

[dminor]

I don't have a strong opinion, but I think it would be less surprising if und were sorted alphabetically. I was surprised when I first noticed that und was sorted separately.

[sffc]

I think we should treat "und" as a language code to be sorted alphabetically, like "mul" and other special codes. Ultimately this will just be less surprising for people.

• @Manishearth, is this okay with you?

Marking this as a good first issue!

[Manishearth]

Yeah it's fine!

[sffc]

OK, so the Ord should be alphabetical for Language and LanguageIdentifier now that #1695 is landed.

However, it still may not be perfect for Locale. The Ord impl for Locale relies on the derived Ord for its entire tree, which works only insofar as everything in the tree is alphabetical. The problem is that it's not:

1. The Extensions map does not reflect the fact that Other extensions may be not in alphabetical order
2. There's no handling of cases when a locale with extensions sorts above a locale without extensions; for example, "und-fonipa" should sort before "und-u-foo", even though a nonempty variants array sorts after an empty one.

[sffc]

Discuss: Is it better to ship an Ord which may change, or ship no Ord at all?

[sffc]

Discussion:

• @robertbastian - We have normalizing_eq and strict_cmp, which are both more clear than an Ord implementation.
• @zbraniecki - I'm okay not shipping Ord.
• @Manishearth - The main downside of not having Ord is that people can't put these in maps and things. But you can write your own wrapper.
• @zbraniecki - We could document what you need to do.
• @robertbastian - We could have wrapper structs that implement the particular behavior.
• @sffc - I think it's useful to have Ord for compatibility with BTreeMap, etc. It should use the string-like sorting.
• @zbraniecki - The fact that "und" sorts in the 'U's is an artifact of BCP-47. Ideally it should sort at the top of the list.
• @sffc - I think we have three options: (1) keep the Ord impls on both and make them strict; (2) keep it on LanguageIdentifier only; or (3) don't implement Ord and keep this issue open.
• @zbraniecki - I prefer (3) because there is a philosophical debate and we should not squat Ord if we're not sure what it should do.

Conclusion: Remove both Ord impls and hopefully everything will work. If it doesn't, consider adding wrapper structs as @robertbastian suggested.