Do we have the wrong behaviour for :param + default?

[leonerd]

The more I use this, the more I feel that we got the defaults wrong with field :param with a defaulting expression.

The current behaviour says that a field with :param and a defaulting expression attached with the = operator, will only apply the default if the caller did not even pass in a named parameter to the constructor at all. Any value at all - even undef - will override this default. We added the notion that fields can be written //= to express that they want the default to also replace an undef.

But basically every single time I add a field $name :param with a default, I end up wanting to put the //= default on it. I basically never care about undef being a thing. undef should behave like missing. Across 12 years, over two hundred CPAN modules and well over a thousand .pm files, I think I could count maybe two or three times I have cared about the distinction between passing undef and not passing anything. It feels like every single time I write //= I begin to wish that it should have been the normal behaviour for just writing = and in the rare case you actually did care to distinguish undef from missing, you'd want to draw special attention to it.

So maybe in that rare case you'd have to write something like one of these:

field $x :param_or_undef = "default";
field $x :param :allow_undef = "default";

I dunno. I don't really like those spellings. We should find something better. But overall, I think we might want to consider making the "normal" thing of

field $x :param = "default";

apply the default on both missing and present-but-undefined values being passed to the constructor, and require the class author to explicitly request differently if that is what they really mean. I think it would avoid surprises on both sides.

[leonerd]

Furthermore I don't really ever think I'd use ||=. So that can likely go.

At which point if there's only field :param = DEF vs field :param_or_undef = DEF then we lop off an entire problem with the adjust-block syntax on these. Now there is only one = operator syntax permitted, so we wouldn't need a way for field $name { BLOCK } to have to notate = vs //=. That entire problem goes away.

[Ovid]

I think I agree with this. Caring about the distinction between new() and new( param => $maybe_undef ) isn't something I normally do, except in very odd edge cases. I'm happy to have that edge case handled with a less common syntax, though I'm unsure what that syntax should be.

:param and ;param_or_undef means the code handling it has to handle the special case of both being present and throwing an error.

:param and :allow_undef means the code handling it has to handle the special case of having :allow_undef without :param and throwing an error.

I'm not saying they're bad, per se, but we've worked so hard to prevent illegal combination that maybe a we can find a way to continue that? What about this?

field $foo :param(?)       = 'default'; # allow undef to be passed and not use the default
field $foo :param(is_foo?) = 'default'; # same thing, but allow is_foo to be the constructor parameter name

Not convinced by my syntax, either, because it doesn't seem intuitive.

[dakkar]

copying here what I wrote on fedi:

:param fields, with the default values, are conceptually declaring the signature of $class->new

for subroutine signatures, = means "use the value if the argument was not there"; with recent changes, we'd have sub x( $x //= "was undef", $y ||= "was false", $z = "was not passed")

for consistency, I say:

field $x :param //= "was undef";
field $y :param ||= "was false";
field $z :param = "was not passed";

[leonerd]

Yeah, it's unfortunate that subroutine signature params already work this way. It may turn out that becomes the main design reason why they should stay at the current behaviour, so at least it matches. Plus then perhaps if everyone gets used to doing field :param //= ... all the time, maybe they'd remember to do that for signature params more often as well.

[Grinnz]

I can't say whether I would miss it given that attributes are already very different than a hash-based object, but I use the existence of attributes that can be undef quite often as a measure of whether a value has been cached.

[leonerd]

Oh certainly. Since fields are just lexical variables, they will definitely obey the same "can be undef or defined" behaviours as regular lexicals. This issue is purely about whether constructors should, by default, distinguish between named parameters that are simply not present, vs explicitly present but with a value of undef. It mostly matters in cases like this:

class MyApp {
  field $timeout :param = 20;
  ...
}

GetOptions(
  'timeout|t=f' => \my $TIMEOUT,
) or exit 1;

MyApp->new( timeout => $TIMEOUT )->run;

It's clear from a casual inspection of the code here that we intended the default timeout of 20 to apply if if the user didn't specify something different on commandline. But since the constructor was explicitly passed a timeout => undef value, that didn't apply. More correct ways to write this would be either of the following:

field $timeout :param //= 20;

# or

MyApp->new(
  (defined $TIMEOUT) ? ( timeout => $TIMEOUT ) : (),
)->run;

and honestly either of those feel a bit untidy. It would be nice if the normal behaviour just DWIM'ed.

[Grinnz]

I think the main instance where the current behavior would be useful is when undef is actually a valid and meaningful value and not the default, so someone may wish to pass it. It's not the most common but it does happen. Random example that comes to mind, an attribute that specifies an encoding layer and defaults to UTF-8 but can be set to undef to disable encoding.

[leonerd]

After much deliberation, thinking, discussion on IRC, Mastodon, and so on, I have come to the conclusion that "Yes, we have the wrong behaviour by default", but also that we can't change it. It's somewhat annoying that //= is what you wanted to write most of the time, even though = looks neater and is shorter. But we feel it's a lot more important that fields behave similarly to similar constructions in other places. The distinction between the = and //= operators is the same when considering subroutine signatures, and also the pseudo signature-like constructions at the start of Object::Pad's ADJUST blocks:

sub f($x, $y = "default-if-missing", $z //= "default-if-undef") { ... }

ADJUST :params (
  :$x, :$y = "default-if-missing", :$z //= "default-if-undef"
) { ... }

# therefore
field $x :param;
field $y :param = "default-if-missing";
field $z :param //= "default-if-undef";

It is perhaps regrettable that subroutine signatures took that behaviour initially, rather than finding some other notation. But we seem to be stuck with it now.

In an alternate universe, Perl would have added a "hash element exists or" operator (perhaps spelled like ilmari's \\ suggestion), and maybe signature params would default to caring about definedness; allowing you the option to use existence in the rare situations you care by writing \\=. And in that world, us using = by default for fields would be neater here. But alas, this is not that world.