6.3 plisqin-lib/loose🔗ℹ

This variant is on hold. I think it should use the same signatures as the strict variant, except that instead of requiring the programmer to prove the absence of errors, the loose variant requires nothing and only gets in the way when it can prove the presence of an error.

Specifically, that means that supertypes should pass for subtypes. A proc that wants a Number should accept a Scalar, because a Scalar might actually be a Number that just lost type information somwhere. However, a String is definitely not a Number and the loose variant would raise an error in that case.

For nullability the strict variant typically treats "maybe" as "yes". The loose variant would treat "maybe" as "no".