Add check definitions to core built-ins and CPAN libraries

[zmughal]

If checks are going to be part of core and used with non-checked CPAN libraries, there should be a way to define checks on those externally. A few examples from other systems:

• Ada + SPARK: https://archive.fosdem.org/2021/schedule/event/safety_opensource_ada_contracts/
• Python + (mypy, pyright, pytype, PyCharm, ...): https://github.com/python/typeshed
• JavaScript + TypeScript: https://github.com/DefinitelyTyped/DefinitelyTyped
• JavaScript + Flow https://flow.org/en/docs/libdefs/
• Racket + Typed Racket https://github.com/racket/typed-racket/tree/master/typed-racket-lib/typed-racket/base-env
• Clojure + clojure.spec: https://github.com/borkdude/speculative

[Ovid]

If anything, that should be a post-MVP experimental feature. Currently, use Data::Checks only impacts the code in its lexical scope. If we add code to affect code at a distance, this could be extremely hard to debug.

[zmughal]

Agreed, this is for post-MVP.

What I'm suggesting SHOULD NOT have any coercions, so there should not be any action at a distance. My goal with this is that it would be useful annotations for tooling. It would also be necessary for defining the check definitions of XS subs without having to create an extra wrapper sub (and possibly for FFI::Platypus integration as well).

I'll try to start an experiment with this and https://github.com/orgs/Perl-Oshun/discussions/41 to show what I'm getting at.

[duncand]

Something that would be useful is for Perl to gain something analogous to a strict mode such that all the built-in operators and routines effectively have checks defined for their parameters, so that for example passing a string to numeric addition will error rather than coerce. These would not be user-defined alterations to built-ins, but rather ones defined by Perl itself, which are opt-in for backwards compatibility reasons.

[zmughal]

Yep, this is exactly what I was thinking about wrt Damian's spec that includes checks for OP[op] which checks operator overloading.

The check can't be based on STR though as defined in the spec. STR currently includes things that have '""' (stringification) overloading. There are many types that have stringification which may also overload say + (addition) --- PDL being the example I'm most familiar with. So the checker would need do something like

operands ∈ IV | UV | NV | OP[+]

[zmughal]

This could also be an opportunity to better model the semantics of how the type of IV/UV/NV SV's changes when they are at the limits of their underlying C representations: https://stackoverflow.com/a/25083776. If we are using a check that indicates a range, we can know if there will be a loss of precision or change from IV/UV to NV or IV to UV.