antonagestam
`Locale` as a phantom type
Could it be feasible to introduce a Locale phantom type? Perhaps more narrowly a "http locale" type, following the rules of the Accept-Language header specification (https://httpwg.org/specs/rfc7231.html#header.accept-language). I don't mean that Locale would represent the whole header value but rather that the header value would be split into multiple locales.
I'd be happy to include this. I think it would make sense to implement it in the same way as CountryCode, e.g. a union of a Literal and a phantom type. What do you think?
Perhaps it's possible to pair it with a CI job that checks for compatibility against this list? https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry
(Assuming the reasoning here is correct: https://stackoverflow.com/a/37062190)
I'd be happy to include this. I think it would make sense to implement it in the same way as CountryCode, e.g. a union of a Literal and a phantom type. What do you think?
Hm, I don't think it's viable with a Literal, since the matrix of the language subtag registry (your link) is massive.
I've read that RFC 5646 specifies 2 classes of conformance "well-formed" and "valid" (https://www.rfc-editor.org/rfc/rfc5646#section-2.2.9) what if phantom types, per default, checks that a LanguageTag is "well-formed"? (Perhaps with the duplication validation of a "valid" language tag)
And what if, in replacement of the Literal approach, we try to make it simple to configure/extend LanguageTag to specify which subtags are supported?
What I'm trying to say here is if we can find a way to avoid phantom types shipping with a massive fixture, the language subtag registry, but still allow for users to have a simple way to "plug in" the parsed language subtag registry, or a subset of it for additional validation purposes.
@flaeppe Did you land on anything with regards to the possibility of introducing types for describing the set of rules that locale codes adhere to? I don't remember all the details, but it sort of seems we shouldn't introduce a Locale type, but (in place of a better name for now) an AdheresToLocaleTagRules type?
I haven't dug any deeper into it, actually. I started off with hard coded locale strings to begin with, and haven't attempted to create anything more sophisticated.
I agree with your reasoning here. A Locale type is probably quite a bit "off topic" regarding a phantom type. Although its rule system might fit in.