Perl Subroutine Signatures Opinion Blog

This site is an opinion blog about Perl Subroutine Signatures. Subroutine Signatures is plan to added to Perl in the near future. I have a very strong concern in the future of Perl, so I created an independent site about sub signatures. My name is Yuki Kimoto. I'm Perl Light User. I have no media power, community power, political power, and big company power. I just feel and talk about the heart of a weak perl user without a voice.

Risk increased by checking the number of subroutine arguments

The current subroutine signature specification checks the number of subroutine arguments.

Many people think that this reduces the mistake of checking for incorrect argument count. 

sub foo ($args1, $args2) {
  
}

# Exception occur for argument count is difference
foo(1, 2, 3);

On the other hand, there is actually risks of increasing by checking the argument count.

Unexpected exception due to later increase of subroutine arguments

I yet see the discussion that unexpected exception due to later increase of subroutine arguments.

I will explain this with a sample.

First, a subroutine is defined with one argument. 

sub foo ($num) {
  
}

User use this subroutine in many place. 

foo(1);

foo(2);

foo(3);

After a while, you want to pass options to this function and change the code to: 

sub foo ($num, $opt) {
  $opt //= {};
}

The user believes it is the same as the following change: 

# Before
sub foo {
  my ($num) = @_;
}

# After
sub foo {
  my ($num, $opt) = @_;
}

Long-time Perl users know that this change doesn't break the source code and this is how it works.

This change is a long practice for Perl users and has been going on for a long time.

On the other hand, checking the number of arguments in a subroutine signature yields different results. 

# Unexpected exception
foo(1);

# Unexpected exception
foo(2);

# Unexpected exception
foo(3);

"The program is broken. An exception is thrown in an unexpected place!"

There is a risk of adding unexpected bugs by checking the number of subroutine arguments.

Should I use the default value?

Such an answer seems to be returned to the above problem.

"Should I use the default value?" 

sub foo ($num, $opt = {}) {

}

This is work well in fact.

What is the problem I feel about this?

This is unintended behavior for users who have been using Perl for a long time.

Perl users generally do not expect Perl to be constrained.

Perl users expect that there are no constraints by default.

The presence of constraints by calling the module is the user's choice, but the subroutine signature is a core feature.

If Perl user write the following for long-standing habits, code is broken. 

sub foo ($num, $opt) {
  $opt //= {};
}

"Oh, in production code, an unexpected exception has occurred! Subroutine signature increases unexpected risk!"

Are we just thinking that adding constraints reduces the risk of mistakes?

Want to add to the discussion that an unexpected exception can break your production code?

Do Perl subroutine signatures require a constraints of number of arguments?

Isn't it essential?

Is checking the number of subroutines compatible with Perl's dynamic mechanism?

Content
Giblog