Spec proposal: Allow numeric annotations on strings

[clarfonthey]

Since #216 definitely seems like out-of-scope, one potential alternative would be to allow numeric suffixes on strings, such that, for example, (i64)"1234" would be "similar" to typing (i64)1234. (Note that I don't say "equivalent".)

They're not equivalent in the sense that these values are still just strings with type annotations, and so this doesn't affect the actual KDL spec beyond adding these reserved type annotations. However, for the schema spec, the query spec, and anyone wishing to conform KDL values to a schema, these strings will be permissible as if they were written directly as numbers with the appropriate type annotation, assuming they're valid KDL numbers.

However, the difference here is that some implementations may choose to support parsing numbers that are not currently allowed by the KDL spec. Specifically, this would allow parsing things like non-decimal floats using syntax like 0x1.2p3.

Additionally, the reserved string annotation (number) should also be allowed, for cases where no specific numeric type is desired, but the user would like to treat this string as a number.

---

Here are the specific changes that would be required:

• To the spec:

  • The spec should add number to the reserved type annotations for strings, which indicates that the value should be interpreted as a number.
  • All of the valid number type annotations should be allowed for strings as well.

• To the query spec:

  • Matchers must allow strings annotated with number or any reserved numeric type annotation to match numeric matchers (like [val() > 0]) if they are a valid KDL number, but may allow more strings than this according to custom syntax.

• To the schema spec:

  • Similarly to the query spec, number validations must permit strings with reserved numeric type annotations if they are valid KDL numbers. The decision for what to do with other strings is up to the implementation.

---

Basically, the desire here is to permit implementations to annotate strings as integers if they use nonstandard KDL syntax, while still remaining syntactically valid KDL.

[zkat]

This seems good!

[zkat]

Thinking about it more: I'm not sure it's a good idea to make the query spec and schema spec changes. They might place an undue burden on implementations as to how they represent KDL documents (or even whether they can wrap certain other libraries. Type annotations in KDL are suggestions, and are never expected to actually represent what they claim to represent, and they're entirely optional. Requiring special behavior from the query and schema specs breaks this.

Thinking further, if a number is a valid KDL number (which imo should be the only time (number) is applied to a string), then having the (number) annotation for strings is essentially useless: just represent it as a KDL number and move on, that's why we have data types.

Ditto for all other numeric annotations on numbers.

The only case where I think it might be prudent to use annotations for "numeric" strings is when doing what #216 was trying to do: that is, represent things like hex floats. Unfortunately, I don't see a portable path forward for also letting the query and schema specs support this that won't cause all sorts of other problems for implementations (and a lot of potential inconsistency that will reduce portability).