You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
any value may be converted to [...] a Boolean truth value using the expression bool(x).
This FR would consider relaxing this to allow truth-checking to fail for certain types, so e.g. if some_application_defined_type: could be an error.
This would enable banning (via a dynamic error) certain patterns that are error-prone, such as Bazel's select, where a boolean could be inadvertently conflated with an object wrapping a computation yielding a boolean. See bazelbuild/bazel#14506.
Downsides: This would effectively prohibit programmatically taking the truthiness of arbitrary values, including where this is done implicitly (without calling bool()), and break existing code that does this. A more minor detail is that it would require implementaitons (particularly the Java interpreter) to propagate an exception where one is not declared today.
Alternatives: Rely on linting, style guides, and documentation to mitigate the damage caused by that kind of confusion.
Personally I'm hesitant to restrict truth-checking in this way.
The text was updated successfully, but these errors were encountered:
The counterargument is that almost every usage of a select() as a bool is a bug, including usages that arise from passing them to libraries that assume the given value is truth-able. If the library owner is not expected to handle such a value then it shouldn't hurt readability. (That "if" is perhaps suspect though.)
The spec requires that
This FR would consider relaxing this to allow truth-checking to fail for certain types, so e.g.
if some_application_defined_type:
could be an error.This would enable banning (via a dynamic error) certain patterns that are error-prone, such as Bazel's
select
, where a boolean could be inadvertently conflated with an object wrapping a computation yielding a boolean. See bazelbuild/bazel#14506.Downsides: This would effectively prohibit programmatically taking the truthiness of arbitrary values, including where this is done implicitly (without calling
bool()
), and break existing code that does this. A more minor detail is that it would require implementaitons (particularly the Java interpreter) to propagate an exception where one is not declared today.Alternatives: Rely on linting, style guides, and documentation to mitigate the damage caused by that kind of confusion.
Personally I'm hesitant to restrict truth-checking in this way.
The text was updated successfully, but these errors were encountered: