Simplify Mappings
I was looking at various implementations of YAML and one feature that stood out as not always having uniform behavior are complex mapping keys, e.g.
---
? [1,2,3]
: [ "one", "two", "three" ]
? [3,4,5]
: [ "three", "four", "five" ]
Some programming languages don't support that kind of associative map out of the box -- instead keys are limited to strings/symbols. So either they just don't support this, or they have to implement a special mapping class just for YAML.
Now, if that was all there was to it, I wouldn't suggest anything different for YAML 2. But in looking at ways to simplify the spec, this stands out because there is another mapping type that YAML acknowledges but doesn't have a built-in notation for, namely, !!omap. So using that same idea, there could be an !!amap (associative mapping).
--- !!amap
- - [1,2,3]
- [ "one", "two", "three" ]
- - [3,4,5]
- [ "three", "four", "five" ]
That would be the only way to use complex keys, so there would be no need for ? syntax at all.
This idea also lends itself to YAML having a new fundamental scalar type, the symbol, i.e. !!sym. Essentially symbols are the same as strings, but given a different type to differentiate them. All mapping keys would be symbols. So for instance:
{ 1: one, 2: two, 3: three }
This would not be a !!int : !!str mapping, but !!sym : !!str. Because they are mapping keys, the numbers are interpreted as symbols, not integers.
While the symbol type is not strictly required, and all mapping keys could just be !!str, I have also noticed numerous languages add some kind of support for symbols in YAML (e.g. a string prefixed with :.) So that's another reason to consider them as a new type. Any language that doesn't support symbols can fallback to strings, which is fine because the difference is primarily semantic (effecting only how they are stored in memory) and have no behavioral significance to YAML.
We should also note, JSON does not support complex keys.