Mailing List Archive

On 2022-01-23 12:16 p.m., Juerd Waalboer wrote:
> Paul "LeoNerd" Evans skribis 2022-01-19 17:59 (+0000):
>>  * As a variant of the above; you can't even see the count of passed
>>    arguments in order to distinguish no-argument from being explicitly
>>    passed undef (or whatever the param default is)
>>      sub signatured($x = undef) {
>>        # impossible to distinguish signatured() from signatured(undef)
>>      }
>
> A simple workaround is possible by introducing a new undef-like value that has
> this very specific purpose:
>
>     use Scalar::Util qw(refaddr);
>     use constant NONE => \do { my $x };
>     sub _provided($x) { ref($x) && refaddr($x) == refaddr(NONE) }
>
>     sub bar($self, $new = NONE) {
>         $self->{bar} = $new if _provided($new);
>         $self->{bar};
>     }
>
> As checking arity for combined getter/setter methods is incredibly common, maybe
> it would make sense to have a very tiny module, maybe even core, that exports
> these, or to add them to Scalar::Util.
>
> Of course, this depends on not using the constant for other purposes. I think
> that's mostly a matter of documenting that the behavior of any other use of the
> constant is undefined.

I still oppose as wrong-headed the concept of using such sentinel default values
to try and detect when no argument is passed. The only use of such default
values is when you don't care to distinguish between users explicitly passing
that value from them not passing anything. When you actually want to
distinguish them not passing a value, DON'T use defaults, and instead use "@" to
capture the list and test the list for presence of an element. -- Darren Duncan

On Monday, 24 January 2022, 07:50:33 CET, Darren Duncan <darren@darrenduncan.net> wrote:

> I still oppose as wrong-headed the concept of using such sentinel default values
> to try and detect when no argument is passed.  The only use of such default
> values is when you don't care to distinguish between users explicitly passing
> that value from them not passing anything.  When you actually want to
> distinguish them not passing a value, DON'T use defaults, and instead use "@" to
> capture the list and test the list for presence of an element. -- Darren Duncan

Then how do we fix the issue? What we *want* to know is how many arguments were passed to a variadic sub. You have this as an earlier example:

    sub signatured(@maybe_x) {
        if (scalar @maybe_x > 0) {
            # we were given an argument, which may or may not be undef
        }
        else {
            # we were not given an argument
        }
    }

You've sort of turned @_ into @maybe_x and now you can pass 20 arguments to it, killing one of the strongest features of signatures. Both your example and @_ are to attempts to determine how many arguments were passed to a sub. Imagine if we had a $^NUM_ARGS variable (terrible name, though I think someone else suggested it):

    sub name ( $self, $name=undef ) {
        if ( $^NUM_ARGS == 2) {
            $self->{name} = $name; # even if undef
        }
        else {
            return $self->{name};
        }
    }

By decoupling the signature from knowing how many args are passed, the solutions is much cleaner and we can't pass 20 arguments to the sub.

Best,
Ovid
-- 
IT consulting, training, specializing in Perl, databases, and agile development
http://www.allaroundtheworld.fr/. 

Buy my book! - http://bit.ly/beginning_perl

On 2022-01-23 11:01 p.m., Ovid via perl5-porters wrote:
> On Monday, 24 January 2022, 07:50:33 CET, Darren Duncan <darren@darrenduncan.net> wrote:
>
>> I still oppose as wrong-headed the concept of using such sentinel default values
>> to try and detect when no argument is passed.  The only use of such default
>> values is when you don't care to distinguish between users explicitly passing
>> that value from them not passing anything.  When you actually want to
>> distinguish them not passing a value, DON'T use defaults, and instead use "@" to
>> capture the list and test the list for presence of an element. -- Darren Duncan
>
> Then how do we fix the issue? What we *want* to know is how many arguments were passed to a variadic sub. You have this as an earlier example:
>
>     sub signatured(@maybe_x) {
>         if (scalar @maybe_x > 0) {
>             # we were given an argument, which may or may not be undef
>         }
>         else {
>             # we were not given an argument
>         }
>     }
>
> You've sort of turned @_ into @maybe_x and now you can pass 20 arguments to it, killing one of the strongest features of signatures. Both your example and @_ are to attempts to determine how many arguments were passed to a sub.

My example was the simplest version; in reality the "@foo" would only be used
for the portion of the signature which is variadic, and any arguments that would
always be passed are listed first as usual, eg:

sub signatured($x, $y, @maybe_z) { ... }

Also I feel that when people are designing their subs properly, the number of
optional parameters would be very few, usually zero, and otherwise the most
common case would be exactly one parameter is optional, such as the combined
getter/setter. When you legitimately have a large number of optional arguments,
that's when named arguments should be used. Legitimately having more than 1
optional positional argument only makes sense when each additional one is only
used when all prior optional ones are also used.

Whenever parameter defaults are used, those defaults should always be a valid
value of the parameter's data type, the same thing the user could have passed in
explicitly but chose not to. So typically that is zero if its a number, or
false if its a boolean, and so on, not undef or some weird sentinel.

> Imagine if we had a $^NUM_ARGS variable (terrible name, though I think someone else suggested it):
>
>     sub name ( $self, $name=undef ) {
>         if ( $^NUM_ARGS == 2) {
>             $self->{name} = $name; # even if undef
>         }
>         else {
>             return $self->{name};
>         }
>     }
>
> By decoupling the signature from knowing how many args are passed, the solutions is much cleaner and we can't pass 20 arguments to the sub.

Now I actually like this proposal of yours a lot in principle. Having another
variable with the count that can be consulted. And if we had that then it would
be an elegant solution that means we can avoid the very problematic idea of
sentinel values and not need slurpy "@foo" to deal with the variadic.

That being said, while it would mean a change to signatures, likely the best way
to implement this is extend the signature syntax where one can declare a
non-special lexical $foo to hold the argument count if they want it.

Here's an example I'm just making up:

sub name ( $self, $name=undef, #$num_args ) { ... }

In that case, $num_args contains the count rather than declaring a parameter.

See also as I recall Raku supports special syntax for declaring the $self as
well, like this:

sub name ( $self: $name ) { ... }

So it would be a similar idea.

And we're not using up some special $^FOO when we don't really need to.

-- Darren Duncan

By the way Ovid, I don't know if this was your thought, but given how the timing
of various things seem to be going right now, I feel that it would be welcome to
get official signatures out now, given that Corinna is waiting until after this
Spring's Perl release.

Because I feel it would be best for relevant parts of Corinna, anything to do
with method declarations, to build on the more general sub signatures and not
invent its own features that are only for methods when they are conceptually.
orthogonal.

In particular, assuming the usefulness of and best practice to use named
arguments for Corinna object constructors or cloning methods or multi-setter
methods etc, I feel that this shouldn't be added for methods without
simultaneously or previously adding it for regular subs.

-- Darren Duncan

On Fri, 21 Jan 2022 12:25:16 +0000
Dave Mitchell <davem@iabyn.com> wrote:

> So:
> for 5.36, add warning;
> for 5.38, remove @_ populating, and if we're lucky, stuff like
> aliasing will also be in 5.38 - otherwise we tell people to revert to
> non-signature subs for now for the hard stuff.
>
> Personally I would still much prefer to add warnings and disable @_
> on the same release: that way there's not a release or two where
> people get warnings but everything still seems to work; so they add
> 'no warnings foo' and everything continues being fine, then all their
> code breaks a release later.

To this end, I have been working on a branch to print those warnings:

https://github.com/Perl/perl5/pull/19346

It sounds like we're in agreement on that part at least. Perhaps you
could give that one a review and at least we can get that part ticked
off.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

On Mon, 24 Jan 2022 07:01:46 +0000 (UTC)
Ovid via perl5-porters <perl5-porters@perl.org> wrote:

> Imagine if we had a $^NUM_ARGS
> variable (terrible name, though I think someone else suggested it):
>
>     sub name ( $self, $name=undef ) {
>         if ( $^NUM_ARGS == 2) {
>             $self->{name} = $name; # even if undef
>         }
>         else {
>             return $self->{name};
>         }
>     }

I've often suggested it as `argc` or variations thereon:

On Tue, 7 Dec 2021 18:02:23 +0000
"Paul \"LeoNerd\" Evans" <leonerd@leonerd.org.uk> wrote:

> In these situations I think it could be quite easy to
> permit a `builtin::argc` to allow it:
>
> use builtin 'argc';
>
> sub red($self, $new = undef) {
> $self->{red} = $new if argc > 1;
> return $self->{red};
> }

https://www.nntp.perl.org/group/perl.perl5.porters/2021/12/msg262142.html

Dave M has rather strongly objected to it:

On Thu, 9 Dec 2021 15:01:21 +0000
Dave Mitchell <davem@iabyn.com> wrote:

> using the arg count as a way of determining whether a default arg
> was passed etc, is awkward, ugly and error-prone for all but the
> simplest subs:
>
> sub foo ($self, $base, $action, $flags, $result, $x, $y = 0, $z =
> 0) { my @point = ($x);
> push @point, $y if @_ > 6;
> push @point, $z if @_ > 7;
> $self->do_point(@point);
> ....
> }
>
> whereas the query params proposal allows:
>
>
> sub foo ($self, $base, $action, $flags, $result,
> ?@point,
> $x, $y = 0, $z = 0)
> {
> $self->do_point(@point);
> ....
> }

https://www.nntp.perl.org/group/perl.perl5.porters/2021/12/msg262156.html

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

On Monday, 24 January 2022, 15:59:55 CET, Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> wrote:


> Ovid via perl5-porters <perl5-porters@perl.org> wrote:
> > 
> > Imagine if we had a $^NUM_ARGS
> > variable (terrible name, though I think someone else suggested it):
> >
> >     sub name ( $self, $name=undef ) {
> >         if ( $^NUM_ARGS == 2) {
> >             $self->{name} = $name; # even if undef
> >         }
> >         else {
> >             return $self->{name};
> >         }
> >     }
> 
> I've often suggested it as `argc` or variations thereon:
<snip>
>
> https://www.nntp.perl.org/group/perl.perl5.porters/2021/12/msg262142.html
>
> Dave M has rather strongly objected to it:

As an aside, but something we might want to keep in mind for future work, many languages simply don't have this issue because of method overloading:

    public void someMethod ( int number )  {
        // do something  
    }

    public void someMethod ( int number, String name ) {
        // do something else
    }

    public void someMethod ( int Number, SomeClass obj ) {
        // do something else
    }

It's clean, easy to read, and handles dispatching nicely. Of course, ambiguities can arise and in the Java examples above, dispatching is based on the number of arguments *and* the type of arguments. 

Allowing this in Perl would be a win because, IMHO, it's easier to read and matches existing, well-known conventions in other languages:

    method name () { return $name }
    # or method name :multi () { return $name }
    method name ( $new_name ) { $name = $new_name }
    # or method name :multi ( $new_name ) { $name = $new_name }

No, I'm not suggesting we do that, but this is (to me) much easier to follow. If types get incorporated at some point in the future, I have a ton of code that could be simplified by dispatching on type rather than if/else blocks. Overloading methods/subs allows us to have logically separated blocks of code for logically separate things.

Again, this is not a suggestion or a recommendation, but something to keep in mind. I'm happy to see signatures get out the door in their current state.

Best,
Ovid
-- 
IT consulting, training, specializing in Perl, databases, and agile development
http://www.allaroundtheworld.fr/. 

Buy my book! - http://bit.ly/beginning_perl

On Mon, 24 Jan 2022 16:54:16 +0000 (UTC)
Ovid <curtis_ovid_poe@yahoo.com> wrote:

> As an aside, but something we might want to keep in mind for future
> work, many languages simply don't have this issue because of method
> overloading:
...
> Allowing this in Perl would be a win because, IMHO, it's easier to
> read and matches existing, well-known conventions in other languages:
>
>     method name () { return $name }
>     # or method name :multi () { return $name }
>     method name ( $new_name ) { $name = $new_name }
>     # or method name :multi ( $new_name ) { $name = $new_name }

You mean like

use v5.26;
use Syntax::Keyword::MultiSub;
use experimental 'signatures';

multi sub max() { return undef; }
multi sub max($x) { return $x; }
multi sub max($x, @more) { my $y = max(@more);
return $x > $y ? $x : $y; }

-- https://metacpan.org/pod/Syntax::Keyword::MultiSub

Doesn't yet support `multi method ...` but I keep meaning to get around
to starting implementing that.

> No, I'm not suggesting we do that,

Oh, I am ;)

> but this is (to me) much easier to
> follow. If types get incorporated at some point in the future, I have
> a ton of code that could be simplified by dispatching on type rather
> than if/else blocks. Overloading methods/subs allows us to have
> logically separated blocks of code for logically separate things.
>
> Again, this is not a suggestion or a recommendation, but something to
> keep in mind. I'm happy to see signatures get out the door in their
> current state.

Yup - that's part of my grand design for 2025 - obligatory link to

https://archive.fosdem.org/2021/schedule/event/perl_in_2025/

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

On Monday, 24 January 2022, 20:22:52 CET, Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> wrote:

> You mean like
>
>   use v5.26;
>   use Syntax::Keyword::MultiSub;
>   use experimental 'signatures';
> 
>   multi sub max()          { return undef; }
>   multi sub max($x)        { return $x; }
>   multi sub max($x, @more) { my $y = max(@more);
>                             return $x > $y ? $x : $y; }
> 
>   -- https://metacpan.org/pod/Syntax::Keyword::MultiSub
> 
> Doesn't yet support `multi method ...` but I keep meaning to get around
> to starting implementing that.
> 
> > No, I'm not suggesting we do that,
> 
> Oh, I am ;)

What do we do with this?

    sub max :multi(@args) {...}
    sub max :multi(%args) {...}

Because arrays and hashes flatten into a list, unless @args has an odd number of elements, we can't disambiguate them, can we?

Java also has ambiguous cases which fail, but always at compile-time. I don't think we can do that, but I would be delighted to be wrong.

Best,
Ovid
-- 
IT consulting, training, specializing in Perl, databases, and agile development
http://www.allaroundtheworld.fr/. 

Buy my book! - http://bit.ly/beginning_perl

On Mon, 24 Jan 2022 20:09:24 +0000 (UTC)
Ovid <curtis_ovid_poe@yahoo.com> wrote:

> What do we do with this?
>
>     sub max :multi(@args) {...}
>     sub max :multi(%args) {...}
>
> Because arrays and hashes flatten into a list, unless @args has an
> odd number of elements, we can't disambiguate them, can we?

$ perl -Mexperimental=signatures -MSyntax::Keyword::MultiSub
multi sub max (@args) {...}
multi sub max (%args) {...}
Already have a slurpy function body for multi sub max at - line 2.


Compiletime error.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

> On Monday, 24 January 2022, 23:32:04 CET, Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> wrote:
> 
> 
> $ perl -Mexperimental=signatures -MSyntax::Keyword::MultiSub
> multi sub max (@args) {...}
> multi sub max (%args) {...}
> Already have a slurpy function body for multi sub max at - line 2.
> 
> Compiletime error.

I'm sold! (though I'd prefer a modifier instead of a keyword)


Best,
Ovid
-- 
IT consulting, training, specializing in Perl, databases, and agile development
http://www.allaroundtheworld.fr/. 

Buy my book! - http://bit.ly/beginning_perl

On Tue, 25 Jan 2022 07:01:04 +0000 (UTC)
Ovid via perl5-porters <perl5-porters@perl.org> wrote:

> > On Monday, 24 January 2022, 23:32:04 CET, Paul "LeoNerd" Evans
> > <leonerd@leonerd.org.uk> wrote:
> > 
> > 
> > $ perl -Mexperimental=signatures -MSyntax::Keyword::MultiSub
> > multi sub max (@args) {...}
> > multi sub max (%args) {...}
> > Already have a slurpy function body for multi sub max at - line 2.
> > 
> > Compiletime error.
>
> I'm sold! (though I'd prefer a modifier instead of a keyword)

Perhaps so, though I don't think a CPAN module would be able to provide
it in that syntax, which is why I didn't try. Perhaps a future thought
of a core implementation would indeed write it `sub NAME :multi ...`

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

On Mon, Jan 24, 2022 at 07:01:46AM +0000, Ovid via perl5-porters wrote:
> You've sort of turned @_ into @maybe_x and now you can pass 20 arguments to it, killing one of the strongest features of signatures. Both your example and @_ are to attempts to determine how many arguments were passed to a sub. Imagine if we had a $^NUM_ARGS variable (terrible name, though I think someone else suggested it):
>
> ? ? sub name ( $self, $name=undef ) {
> ? ? ? ? if ( $^NUM_ARGS == 2) {
> ? ? ? ? ? ? $self->{name} = $name; # even if undef
> ? ? ? ? }
> ? ? ? ? else {
> ? ? ? ? ? ? return $self->{name};
> ? ? ? ? }
> ? ? }
>
> By decoupling the signature from knowing how many args are passed, the solutions is much cleaner and we can't pass 20 arguments to the sub.

Again, with query parameters this is simple:

? ? sub name ($self, ??$has_value, $value = undef) {
? ? ? ? if ($has_value) {
? ? ? ? ? ? $self->{name} = $value; # even if undef
? ? ? ? }
? ? ? ? else {
? ? ? ? ? ? return $self->{name};
? ? ? ? }
? ? }

$has_value is a boolean value which is true if there are any args
remaining at that point in parameter processing.



--
Dave's first rule of Opera:
If something needs saying, say it: don't warble it.

On 2022-01-31 1:08 p.m., Dave Mitchell wrote:
> Again, with query parameters this is simple:
>
>     sub name ($self, ??$has_value, $value = undef) {
>         if ($has_value) {
>             $self->{name} = $value; # even if undef
>         }
>         else {
>             return $self->{name};
>         }
>     }
>
> $has_value is a boolean value which is true if there are any args
> remaining at that point in parameter processing.

Thanks for the explanation.

I kept hearing references to "query parameters" and they didn't really make
sense to me before in this context.

The only other place I hear "query parameters" is in reference to calling SQL
DBMSs from a program, and "query parameters" mean the same thing as plain old
"parameters", for example when one writes something like:

SELECT foo FROM bar WHERE baz = :quux

... and after you prepare that, each execution binds "quux" to an argument,
because it is a "query parameter".

-- Darren Duncan

On 1/24/22 07:50, Darren Duncan wrote:

> I still oppose as wrong-headed the concept of using such sentinel
> default values to try and detect when no argument is passed.  The only
> use of such default values is when you don't care to distinguish
> between users explicitly passing that value from them not passing
> anything.  When you actually want to distinguish them not passing a
> value, DON'T use defaults, and instead use "@" to capture the list and
> test the list for presence of an element. -- Darren Duncan


I understand what you are saying, and agree to a certain extent, but:


1) If a value is documented to mean 'no-parameter', and only that, if
you explicitly pass that, you get what you deserve. This is different
from using the  generic 'unknown' proposal for this, where unknown can
very well be used as legitimately as a meaningful parameter value.


2) You can always do this in your project, if there is no generic
'no-parameter' value. It's your project/library, you are free to define
such a value and use it. In fact, I think this is what we can suggest
right now as a good technique to solve this problem. Again, if someone
maliciously passes such a value explicitly, they get what they deserve.


I think this is greatly preferable to telling people to use a slurpy
parameter. You just reintroduced @_, as far as my programmer experience
is concerned. I really, really hate that. (Note that I hate the use of
ref_addr too, but that can probably be hidden somewhat.)


Bottom line, I think, if we want to depricate @_ in signatured subs --
which we probably want, as this is the only realistic opportunity to do
so -- there are two techniques (no-parameter and slurpy last param)
which make determining arity possible, while we can think of an even
better way later (soonish!).


HTH,

M4

On Mon, Jan 31, 2022 at 02:00:41PM -0800, Darren Duncan wrote:
> I kept hearing references to "query parameters" and they didn't really make
> sense to me before in this context.
>
> The only other place I hear "query parameters" is ...

It's just a name I made up as part of a proposal.

See this thread on p5p from Nov 2019:

Subject: Jumbo Signatures extensions discussion
http://nntp.perl.org/group/perl.perl5.porters/256677

and in particular this sub-thread:

Subject: Query Parameters
http://nntp.perl.org/group/perl.perl5.porters/256680


--
If life gives you lemons, you'll probably develop a citric acid allergy.

On 2022-01-31 2:04 p.m., Martijn Lievaart wrote:
> On 1/24/22 07:50, Darren Duncan wrote:
>
>> I still oppose as wrong-headed the concept of using such sentinel default
>> values to try and detect when no argument is passed.  The only use of such
>> default values is when you don't care to distinguish between users explicitly
>> passing that value from them not passing anything.  When you actually want to
>> distinguish them not passing a value, DON'T use defaults, and instead use "@"
>> to capture the list and test the list for presence of an element. -- Darren
>> Duncan
>
> I understand what you are saying, and agree to a certain extent, but:
>
> 1) If a value is documented to mean 'no-parameter', and only that, if you
> explicitly pass that, you get what you deserve. This is different from using
> the  generic 'unknown' proposal for this, where unknown can very well be used as
> legitimately as a meaningful parameter value.
<snip>

A problem with this line of reasoning is it prevents the creation of whole
classes of generic routines/operators, ones that are supposed to be
type-agnostic, because it is treating certain things as exceptions.

Would you be happy if Perl didn't have the hash "exists" operator and the only
way to tell if an element was present was to try and fetch it and test the
result for "undef"? A lot of people do it, but its a terrible solution.

I agree that slurpy "@" parameters are not ideal, but having sentinel values as
the only way to know if an argument was passed is worse.

However, there are yet other options.

Dave Mitchell's so-called "query parameters", where each optional parameter is
expressed with 2 names where one of the names is a boolean saying if the
parameter was actually given, would appear to be a good solution.

In any event, a lot of this discussion is effectively on best practices.

Practically speaking it would be best for Perl itself for signatures to support
multiple ways of doing things, supporting non-slurpy with default values plus
slurpy, and each routine writer can use the style they want based on what they
actually need. People can choose to use sentinels, but those who really need to
know about a lack of an argument without using a sentinel are also able to do so.

-- Darren Duncan

On 1/31/22 23:19, Darren Duncan wrote:
> On 2022-01-31 2:04 p.m., Martijn Lievaart wrote:
>> I understand what you are saying, and agree to a certain extent, but:
>>
>> 1) If a value is documented to mean 'no-parameter', and only that, if
>> you explicitly pass that, you get what you deserve. This is different
>> from using the  generic 'unknown' proposal for this, where unknown
>> can very well be used as legitimately as a meaningful parameter value.
> <snip>
>
> A problem with this line of reasoning is it prevents the creation of
> whole classes of generic routines/operators, ones that are supposed to
> be type-agnostic, because it is treating certain things as exceptions.


You are creating a problem that does not exist, I think. Your argument
would hold water if I advocated to use unknown or undef or any other
value that can legitimately be passed as a parameter for this, which I
don't.


If it doesn't make sense to pass no-parameter to a function, do not do
so. Its presence has no other use than signaling there is no parameter,
so it should never be used as a legitimate value. Doctor, it hurts when
I press here.


Because it should never be passed, and only is meaningful as a default,
it can only be passed to a function as a result of a bug by the writer
of the signatured sub that uses it. And bugs are bugs, not features.


> Would you be happy if Perl didn't have the hash "exists" operator and
> the only way to tell if an element was present was to try and fetch it
> and test the result for "undef"?  A lot of people do it, but its a
> terrible solution.


Undef is a legitimate parameter value, that can be legitimately passed.
So this is a non-sequitor.


[...]


> Practically speaking it would be best for Perl itself for signatures
> to support multiple ways of doing things, supporting non-slurpy with
> default values plus slurpy, and each routine writer can use the style
> they want based on what they actually need.  People can choose to use
> sentinels, but those who really need to know about a lack of an
> argument without using a sentinel are also able to do so.


Agree, that was my conclusion too. So in the end it doesn't matter too
much, although I would say both should be in the documentation.


M4