Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Allow can and try functions to return known results with unknown values in the arguments #622

Merged
merged 1 commit into from
Aug 25, 2023
Merged

Allow can and try functions to return known results with unknown values in the arguments #622

merged 1 commit into from
Aug 25, 2023

Commits on Aug 14, 2023

  1. Allow can and try functions to handle more unknown 

    The `can` and `try` functions can return more precise results in some
cases. Rather than try to inspect the expressions for any unknown
values, rely on the evaluation result to be correct or error and base
the decision on the evaluated values and errors.

A fundamental requirement for the `try` and `can` functions is that the
value and types remain consistent as argument values are refined. This
can be done provided we hold these conditions regarding unknowns to be
true:
 - An evaluation error can never be fixed by an unknown value becoming
   known.
 - An entirely known value from an expression cannot later become
   unknown as values are refined.
 - A expression result must always have a consistent type and value.
   only allowing the refinement of unknown values and types.
 - An expression result cannot be conditionally based on the
   "known-ness" of a value (which is really the premise for all previous
   statements).

As long as those conditions remain true, the result of the `try`
argument's evaluation can be trusted, and we don't need to bail out
early at any sign of an unknown in the argument expressions.

While the evaluation result of each argument can be trusted in isolation
however, the fact that different types and values can be returned by
`try` means we need to convert the return to the most generic value
possible to prevent inconsistent results ourself (adhering to the 3rd
condition above). That means anything which is not entirely known must
be converted to a dynamic value.

Evan more refinement might still be possible in the future if all
arguments are evaluated and compared for compatibility, but care needs
to be taken to prevent changing known values within collections from
different arguments even when types are identical.
    @jbardin
    jbardin committed Aug 14, 2023
    Configuration menu
    Copy the full SHA
    6af2870 View commit details
    Browse the repository at this point in the history