develooper Front page | perl.perl5.porters | Postings from December 2017

Urgent subroutine signatures problems

Thread Next
From:
Sawyer X
Date:
December 13, 2017 13:47
Subject:
Urgent subroutine signatures problems
Message ID:
0660a389-867c-052c-274b-b2957eda0a9a@gmail.com
I want to surface two critical subroutine signature issues, one
previously raised by Zefram. These are urgent since they are breaking
issues. We should discuss them and resolve them quickly.

It is better to break more things now than several times over time since
each one resets the clock on the stability of signatures. We might as
well resolve all breaking changes together.

1. Lvalue subroutines are now broken as a result of the placement of
subroutine signatures (RT #132141)[1]:

The reason for this is simple: Lvalue subroutines use the :lvalue
subroutine attribute and subroutine attributes now come after the
signature. Considering subroutine signatures can contain arbitrary code
and :lvalue changes compilation, this, in effect, means that those
features are now mutually exclusive. You cannot use :lvalue to affect
compilation of any code in subroutine signatures.

One way to fix this would be to move subroutine signatures following
subroutine attributes. Another fix would be to allow them both before
*and* after, putting the responsibility on the user of using :lvalue
(and such attributes that alter the subroutine in similar ways) before
defining the subroutine signature. These solutions can be pretty
fragile. Another option is to recognize which attributes should appear
only before signatures and trigger an error if they appear after the
signatures instead.

2. Having signatures available without explicitly enabling them

While we could "use feature" subroutine signatures, it would be even
better if they were simply available without using a pragma. However,
their syntax clashes with prototypes, meaning we can't have them enabled
by default without breaking backward compatibility. We are forced to
hide signatures behind a pragma.

Short-form prototype syntax is a stable feature that works by default on
all versions since 5.002. The :prototype attribute didn't exist until
5.20, so backward-compatible code doesn't even have a choice about how
to use prototypes. It would be wrong to break this.

If the syntax didn't clash, then we could have signatures enabled by
default and not lose backward compatibility. Just as an example of a
clear distinction between signatures and prototypes, Zefram suggested
using square brackets for signatures[2]. This change would allow having
subroutine signatures enabled without any pragma, which is quite appealing.

I think these issues are critical enough at this point to invite the
community at large to provide input and feedback on this. I will be
publishing a blog post on this topic, encouraging people to join the
discussion on it.

Thank you,
Sawyer.

[1] https://rt.perl.org/Ticket/Display.html?id=132141
[2] http://nntp.perl.org/group/perl.perl5.porters/247237

Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About