Add //= and ||=

[schwern]

Defaults are normally applied when the argument isn't passed in at all. This leaves the problem of what to do when an arg is undefined or false.

fun hello($place="World") { print "Hello, $place!\n" }
hello();  # "Hello, $place!
hello(undef);  # "Hello, !"

To fix that you can't have the default in the parameter list, you're back to doing it in the body. Any time the user has to revert to doing parameter parsing in the body that defeats the point of using parameter lists. It's a sign the parameter syntax isn't expressive enough.

fun hello($place) { $place //= "World";  print "Hello, $place!\n" }

Perl programmers do some wacky things with function arguments, but applying a default if the value is undefined or false is pretty common. Perl already has syntax for that, //= and ||=. So just support that!

[mauke]

Any time the user has to revert to doing parameter parsing in the body that defeats the point of using parameter lists.

I strongly disagree with this. I think fun hello($place) { $place //= "World"; ... } is a perfectly good solution if you want to turn an explicit undef into something else. Why complicate parameter lists for a redundant feature?

Real default arguments are different: Without them you can't easily check for the absence of an argument (short of inspecting @_ directly, which defeats the point). I added them specifically to support strict checks on the number of arguments. Functions with variable-length arguments are so common in Perl that strict mode would be useless without default arguments.

applying a default if the value is undefined or false is pretty common.

I don't think it's good style, though.

Perl already has syntax for that, //= and ||=. So just support that!

Or I could tell the programmer to just use the existing constructs. :-)

I'll have to think about this.

[schwern]

Why complicate parameter lists for a redundant feature?

By that argument, the whole module is redundant. Being redundant with Perl 5 is fine, Function::Parameters doesn't do anything you can't already do. What it does provide is clarity, type checks, argument checks, and so on. You want people to express their arguments as function parameters. If they don't, if part of it is in the function body, clarity is lost.

I don't think it's good style, though.

We can argue whether it's good style or not later. I think we can agree it's common and it's not so egregious it needs to be stamped out. I'm going to argue you're not going to stop users from doing it and they'll just work around it.

What you're really doing is giving people a reason to not use Function::Parameters. F::P is so much better than manually unpacking parameters that it's worth it to support what you might consider questionable, but very common, style just to get it applied to more code.

And if you don't think it's good style, make it an option that's off by default.

[mauke]

I have somewhat come around on this issue. In the latest commits I've added support for //=.

I'm still on the fence about ||=, so leaving this issue open for now.