develooper Front page | perl.perl5.porters | Postings from February 2022

Re: Things you can't do in a signatured sub

Thread Previous | Thread Next
Martijn Lievaart
February 1, 2022 07:47
Re: Things you can't do in a signatured sub
Message ID:

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 

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.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About