Numeric separators in kebab names

[guybedford]

Came up in considering options for representing enums like:

enum tls-version {
  tls1,
  tls1-1,
  tls1-2,
  tls1-3
}

where it would be useful to be able to write an explicit underscore separator:

enum tls-version {
  tls1,
  tls1_1,
  tls1_2,
  tls1_3
}

It might just still be possible to still retain bijective mapping using names like TlsVersion::TLS1__2 / tls1_2 (double underscoring).

[lukewagner]

Ah, good use case, thanks for filing. So then is the idea to add a second separator character that can only be used to separate digits and let this get idiomatically mapped into different languages' naming schemes? To give the idiomatic-name-mapping enough semantic information to go on, I wonder if we should just focus just on the "numeric version separator" use case (which I can see showing up in many interfaces) in which case . would perhaps be the right separator (. is tentatively used for class.field in #129, but that could be changed to :).

[guybedford]

I was thinking more about having another generic separator option by allowing _ in kebab casing alongside -. Right now that is disallowed because of ambiguity with snake casing, hence my suggestion of a __ in that case. I suppose having a specific numeric separator could be seen as an option, although it would perhaps be unclear why it couldn't also be used as an alphanumeric separator.

In most languages, despite the identifier character restrictions, usually one is still able to have access to both camel casing and underscores, or access to both kebab casing and underscores when needed, while in these namings that isn't a possibility.

[lukewagner]

With the - separator, the language-agnostic understanding is that the hyphen is separating words. I worry that adding a second generic separator makes things muddier unless we somehow say what this separator means and how it differs from - such that different language casing schemes can usefully interpret the separator differently. With a generic _ or __, I don't see how one would interpret it other than "probably emit a _, if you can". With a "numeric version separator" ., I can imagine different languages translating the . differently to match how dotted-versions are idiomatically rendered in their language.