Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mark signatures as stable since 5.020 #19

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Corion
Copy link

@Corion Corion commented Mar 29, 2024

with 5.036

@Leont
Copy link
Member

Leont commented Mar 29, 2024

I'm pretty sure we had a discussion about this before and there were reasons not to do this, but I don't remember the details. @rjbs ?

Copy link
Member

@ilmari ilmari left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't it be stable as of 5.28? The ordering of attributes vs. signature changed in 5.22 and back again in 5.28.

@Corion
Copy link
Author

Corion commented Apr 18, 2024

Ah - I missed that. I'm happy to move it to 5.28 as well.

@rjbs
Copy link
Member

rjbs commented Apr 18, 2024

From IRC where someone reminded me of this question:

I think the issue was that: "stable" is for when a feature in version X is experimental, but in version X+n it is not and is identical.

In version v5.2x, signatures stopped changing, except they do not warn on use of @_ in a subroutine with signatures. In current perl they do. I think this was the discussion/argument at the time.

Say you use v5.34 and had "use stable 'signatures'". You could use @_ and get no warning. Then up upgrade to some future version, thinking your code was not using something experimental: but it was, it was using @_-in-signatured-sub.

@_-in-signature is not deprecated, in which case we might say it could be removed with warning, and those warnings could come in vX. It is experimental, which mean it can change any time. The user would not be using a stable feature, and would not be getting warnings about it.

So I think I stand by my reasoning.
This may be an argument to deprecate @_-in-signatured-sub ASAP.

@Corion
Copy link
Author

Corion commented Apr 18, 2024

OK - so I'll postpone this PR until after @_-in-signatured-sub is deprecated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants