Hi,

on second reading: the implementation-specific types sound like a very
different use-case than the checked types:

The checked arguments enable ensuring guarantees across implementations
in a single implementation, because the argument checking ontology comes
from the application code and could be provided as library.

The implementation-specific types enable gathering
implementation-specific information but require specific code for each
implementation, because there’s a different argument checking ontology
for each implementation.

My impression is that to make implementation-specific types more
practical to use this would need standardized names for at least some
types to enable code to take advantage of the added information.
Otherwise I’d have to try my code on different implementations and
different versions of implementations to build on that information. And
an update could break my specific code, when the implementation gets
better at optimizing (it could example detect that it can use a 8 bit
integer for a number and then the integer? could turn into
integer-uint8? and my integer-detection code would be broken).

Maybe this could even call for a hierarchy of types, so the returned
implementation-specific type could have a "parent-types" field I could
match against (and which stays valid after updates even if the type
itself grows more specific).

Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
https://www.draketo.de