I just returned from an archaeological dig that uncovered the origin of the 'sanctuary-def/Nullable' special case.
17:
The new implementation defines $.Nullable via $.UnaryType, as this turned out to be simpler. This necessitated the addition of a t.name === 'sanctuary-def/Nullable' check, which is unfortunate. I haven't thought of a simpler way to avoid (Nullable (Nullable (Nullable ...))) infinite recursion.
52:
Removing the requirement that all types referenced in function definitions be in the environment […] removes the need to treat $.Any specially, simplifying internals.
52 also removed the need to treat $.Nullable specially, by removing the only reason to include Nullable ??? in an environment. It was not until #79, though, that this type was removed from the environment in which nullable types are tested. Prior to #79, removing the special case would have resulted in a test failure (for a test that no longer demonstrated a valid use case).
I just returned from an archaeological dig that uncovered the origin of the
'sanctuary-def/Nullable'special case.17:
52:
52 also removed the need to treat
$.Nullablespecially, by removing the only reason to includeNullable ???in an environment. It was not until #79, though, that this type was removed from the environment in which nullable types are tested. Prior to #79, removing the special case would have resulted in a test failure (for a test that no longer demonstrated a valid use case)./cc @albrow, @svozza, @wmrowan