Skip to content

Use new reserved-for-perl syntax#24280

Open
khwilliamson wants to merge 2 commits intoPerl:bleadfrom
khwilliamson:pl_
Open

Use new reserved-for-perl syntax#24280
khwilliamson wants to merge 2 commits intoPerl:bleadfrom
khwilliamson:pl_

Conversation

@khwilliamson
Copy link
Copy Markdown
Contributor

One commit changes to use this less obtrusive syntax for a symbol added in 5.43.8

The other commit changes two symbols created earlier in the 5.43 series that are so short that they might collide with an XS symbol.

  • This set of changes does not require a perldelta entry.

We now have published that _pl_ as a suffix is reserved for Perl use.
Change this newly created symbol to be of that form, which is less
obtrusive.
They were too short for comfort in not clashing with XS symbols.
@jkeenan
Copy link
Copy Markdown
Contributor

jkeenan commented Mar 23, 2026

In my reading this p.r. qualifies for a 'defer-next-dev' label.

@khwilliamson
Copy link
Copy Markdown
Contributor Author

On the contrary, it is somewhat important to get it into 5.44. It changes two names designed for internal use that are visible everywhere, and are so short that they could have some likelihood of conflicting with an existing symbol. These symbols did not exist in 5.42. No stable code can be affected by their renaming.

@tonycoz
Copy link
Copy Markdown
Contributor

tonycoz commented Mar 30, 2026

"handycommah" in the first commit message

@tonycoz
Copy link
Copy Markdown
Contributor

tonycoz commented Mar 30, 2026

I think the Perl_ is more readable than the _pl_ suffix and only one character longer.

@khwilliamson
Copy link
Copy Markdown
Contributor Author

The problem with Perl_ as a prefix is that it is the unimportant part; existing only for reasons not related to the point of the variable. The suffix form keeps the important part first and foremost. Please consider the possibility that years of seeing the prefix form may have conditioned us to look past it without thinking. But my expectation is that someone with less experience with the way we have always done things would find the suffix form more congenial.

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.

3 participants