BOOL should accept undef

[happy-barney]

Unlike other primitive BOOL should accept undef as well.

There are tons of existing code returning undef as false.

IMHO it's not good idea forcing users to change their existing codebase in order to use newer syntax to add some features.

[Ovid]

I think this sounds like a very reasonable thing. (Edit: Obviously, I needed to think about this more)

[duncand]

I believe in the principle that booleans should be treated the same as numbers/text/the-rest as far as undef goes, either they all include undef or none of them do, and for that matter there should be a version of every one of them that does NOT include undef, whether or not there is a version that does include it.

[tobyink]

@duncand, there's a good reason to consider booleans as separate from numbers and strings with regards to accepting undef.

use warnings;

my $thing = undef;

my $text  = "Hello $thing";  # warns
my $sum   = 42 + $thing;     # warns
do_something() if $thing;    # no warning

Perl itself is happy to treat undef as false in boolean contexts with no warning. So from that perspective, undef is "valid" as a boolean, while it's more questionable as a string or number.

[Ovid]

The problem with booleans as numbers/text/undef, is that there's no semantic information with them. Internally, that kinda works: was that undef supposed to be false or was it an uninitialized variable? However, externally it's a mess. I tire of all the hacks I see to get proper true and false values pass in serialized data such as JSON.

[druud]

On 2023-07-21 16:34, Toby Inkster wrote: @duncand <https://github.com/duncand>, there's a good reason to consider booleans as separate from numbers and strings with regards to accepting undef. use warnings; my $thing =undef; my $text ="Hello $thing";# warns my $sum = 42 +$thing;# warns do_something()if $thing;# no warning Perl itself is happy to treat undef as false in boolean contexts with no warning. So from that perspective, undef is "valid" as a boolean, while it's more questionable as a string or number.

There is value, and there is state. Those are IMO best seen as different dimensions. <undef> could be both a state (represented by an undef-flag) and a value (similar to the float value NaN). Perl has many falsy values: undef, 0, "", "0". A boolean data type adds another falsy value, that is distinguishable from an integer zero. <if> tests the state (or boolean casting) of a value. Any non-zero integer will test as true, so would "from that perspective" be "valid" as a boolean? Does that mean that "BOOL should accept" 42? IMO the BOOL data check should not accept undef.

…

-- Ruud Just to be funny:   perl -E'local $| = 42; say $|'   1

[duncand]

@tobyink Just because Perl doesn't warn when given an undef to a boolean context doesn't mean that undef should be considered a valid boolean when it isn't a valid number or string. An undef logically means unknown or unspecified information in the general sense, so treating it the same as known-to-be-false can produce wrong answers, just as wrong as treating undef as zero or the empty string. While it is reasonable for some programs to treat undef as being equivalent to those default/empty/etc values for a type, users should have the choice to have a bool that explicitly rejects undef, same as they have numbers or strings that reject undef.

[zmughal]

Perhaps something like a LaxBool or Maybe[BOOL] could be done so that the default is stricter? I see there is a parameterised Maybe[ ] in the spec, but only as an example.

[happy-barney]

it's common practice to do empty return and use that function's value in boolean context.
I think that excluding undef from bool will force unnecessary refactoring on potential users, and that we should avoid.

[duncand]

it's common practice to do empty return and use that function's value in boolean context.
I think that excluding undef from bool will force unnecessary refactoring on potential users, and that we should avoid.

This is a non-issue if the course I recommend is followed that 2 versions of the BOOL are provided, one including undef and one without. Given that Oshun has never been in production, there is no existing code using any existing definition of BOOL, so no existing Perl code would have to be refactored one way or the other.

Also when it comes to multiple variants of anything including or not including undef, I believe the version that excludes undef should always have the shorter plainer name, eg plain BOOL/INT/etc should always be the version that excludes undef, as the name fits, what you see is what you get, and longer things like Maybe[BOOL] or BOOL? etc would be the versions that include undef.

[Ovid]

Currently I'm more concerned about the fact that Perl now has native true and false (thank goodness)!. This is currently not handled by BOOL, but I see that Data::Checks::Parser already uses $] to check the Perl version, so this shouldn't be too hard to add.

it's common practice to do empty return and use that function's value in boolean context.

Either you're producing or consuming that value. If you're consuming:

my BOOL | UNDEF  $foo = get_value();

If you're producing:

sub get_value () returns BOOL | UNDEF {...}

You could also argue that the code should explicitly return undef instead of using a bare return, but if it's existing code,that's a behavioral change.

I think that excluding undef from bool will force unnecessary refactoring on potential users, and that we should avoid.

I am very sympathetic towards this idea, but since Perl cannot distinguish between undefined and uninitialized, we're kind of stuck because we don't know which is which for Perl. So let the consumer specify BOOL | UNDEF if they want to take that (admittedly small) risk.

So the concerns seem trivial to resolve with the existing spec. Have I missed something?

Principle of Parsimony: from there, if we decide to allow undef in BOOL, the above still works. If we realize undef in BOOL was a mistake, we can't walk that back without breaking code.

[demerphq]

FWIW, I am with @happy-barney on the question of whether undef is a valid bool. We only introduce "true" booleans to perl recently, and for most of the existence of Perl Larry defined "false" to be "undef", "0", 0 and the empty string, and everthing else to be true (modulo overload). So I think it would be quite counter productive to not have a way to respect that design intent.

It seems to me that the proposal we should have two keywords for booleans, perhaps distinguished by spelling. For instance I could imagine "Bool" and "BOOL". Or I could imagine "Bool" and "Truthy" or whatever, or maybe "PerlBool" and "JsonBool". (I cant remember the spelling convention we chose) I don't think it is helpful to say that only one model of boolean is supported. I could pass in an obect with boolean overloads, and it should pass a bool test.

I understand the invocation of the principle of parsimony here, but i think it is misguided. Perl supports multiple notions of bool, and our checks should as well. I would be very surprised and consider it counter productive to not be able to use "undef" as a "false" value in a place expecting a bool.

I also note that people seem to be saying that bools should be a number or a string, but i consider every unoverloaded ref to be a valid true value, and any overloaded reference could act as a boolean as well, so I think there is a conceptual clash there as well. Related I think the arguments that undef has a specific meaning closer to an SQL "NULL" tend to fall down under the semantics that Larry chose to provide. undef is == to undef and 0, and undef is eq to undef and "" (albeit with warnings), the mutator operators consider "undef" to be a valid initial value silently mapping to 0 or the empty string, and it is considered a valid boolean value in all internal contexts. So the weight of history does not support that "undef" means "no value" in the same sense that SQL NULL means that. We need to accomodate that history, especially as it is particularly useful in many contexts.

A great deal of code depends on

if ($hash{bool_predicate}) { ... }

working the same regardless if $hash{bool_predicate} is 0 or the empty space, /or missing/ and thus undef. Making BOOL not respect this would be problematic IMO and would inevitably need to be changed in the future.

[happy-barney]

@demerphq oh, thanks mentioning overload, raising questions:

• is in fact valid bool value value with overloaded bool conversion ? (in fact, any value with provided overload)
• as far as this are not types (though word check is close to it), maybe implicit coercion can be applied on assignment as well ?
  • if it is blessed and overloaded, accept it
  • if it is not, coerce it

[Ovid]

I agree that undef cannot behave like NULL. I wish it did, but that ship has sailed.

Otherwise, to answer @happy-barney's question, in Data::Checks::Parser, we have this:

    BOOL   => q(( «NONREF» || overload::Method(§,'bool') )),

So a BOOL is anything that is not a reference, or has boolean overloading. NONREF is defined as this:

    NONREF => q(( «DEF» && !Data::Checks::Parser::reftype(§) )),

So yeah, currently it requires it being defined.

You can read the tests here.

(I'm not saying this is how things have to be, I'm saying "that's what the code currently does")

Also, we don't allow implicit coercion anywhere (that I recall) because of this:

my INT $max_size = \@foo;

Currently, it's trivial to do things like this: say $this + $that and if either $this or $that is a reference, it will be quietly (no warnings!) coerced to an integer. Oshun doesn't stop that directly because it applies to assignment, not operators, but we can at least prevent some simple coercion errors.

Any thoughts about applying checks outside of assignment should be post-MVP.

[druud]

On 2023-07-22 10:23, Yves Orton wrote: FWIW, I am with @happy-barney <https://github.com/happy-barney> on the question of whether undef is a valid bool. We only introduce "true" booleans to perl recently, and for most of the existence of Perl Larry defined "false" to be "undef", "0", 0 and the empty string, and everthing else to be true (modulo overload). So I think it would be quite counter productive to not have a way to respect that design intent.

For me this (again) conflates states ("test results") and BOOL values. I see no need for a BOOL data element to support undef. A laxer BOOL-variant can auto-cast undef to false, either always or only at initialization. But I prefer BOOL itself to be strict. What <if> tests, is truthiness, which for a number means "not zero" etc. so that does not depend on BOOL. Similar for ternary, etc. P.S. I also like to see (optional) default values, like in C++, where "int x;" sets x to 0.

[Ovid]

@druud We vetoed default values early on because they tend to be arbitrary. Just because something defaults to false doesn't mean it's false, for example. If we default my UINT $count; to zero, what if there's actually a count, but due to poor code, it's not assigned? What would be defaults on GLOB or HANDLE?