What I am proposing and a hypothetical future refinement types specification can coexist. Sure what I am proposing can be used for refinement types but not at the language level (it may be in Pydantic, but that would only be because one came before the other just like Field(const=["a"]) / StrEnum and typing.Literal, we’re fine with that). And what I am proposing has use cases beyond refinement types which, like it or not, are popular with users, useful and have no proposed alternative, so it would not be a complete waste even if refinement types existed in the type system tomorrow.
I commented on the that thread: TypeForm: Spelling for a type annotation object at runtime - #24 by adriangb
I can’t speak for msgspec but I can say that if refinement types were to be introduced into the language directly Pydantic and Hypothesis would be happy to churn / support both versions just like we’ve done with typing.Literal and other things in the past. Given Pydantic’s popularity (more PyPi downloads than mypy) that should cover a lot of ground with concern for library devs. I think we should let other library or type checker authors speak for themselves (several of them have already been tagged in this discussion). As for end users there is no churn unless the library they use forces them to (and they don’t have to, everything we’re discussing is backwards compatible).