Porters,
On today's PSC call, we were discussing the state of the "use v5.36" bundle, and whether it should turn off the "indirect" and "multidimensional" features. Our consensus was that this *should* happen. For those who want a refresher:
"no feature 'indirect'" disables "indirect object syntax" meaning you can no longer write this:
my $object = new Class (1, 2);
This is useful as a footgun remover, converting a mistake from runtime to compile time. For example, say you're like me and often forget to load Try::Tiny…
dinah:~$ perl -c -e 'try {1 };'
-e syntax OK
dinah:~$ perl -e 'try {1 };'
Can't locate object method "try" via package "1" (perhaps you forgot to load "1"?) at -e line 1.
dinah:~$ perl -c -e 'no feature "indirect"; try {1 };'
syntax error at -e line 1, near "try {"
-e had compilation errors.
The first two stanzas show the current behavior: the code compiles but won't run.
The third shows the behavior without indirect: it fails to compile.
This syntax has long been discouraged. Existing code will continue to work, and this will only affect code that disables the syntax. Some example code in documentation may now be "wrong" when put into place with use v5.36.0 in place, but that's a risk we're already taking with other features.
My take: indirect syntax will be around more or less forever.
"no feature 'multidimensional'" turns off the weird behavior of hash subscripting on lists as keys. What? It means this:
# These two lookups are effectively identical:
$hash{ 1,2,3 }
$hash{ join "$;", 1, 2, 3 }
Why? Historical reasons. It's neat, I've used it. But it's easy to simulate by other means, and mostly seems to show up as a footgun. This won't break existing code, because it will require opting-in.
My take: someday we might deprecate this behavior, but not this year anyway!
--
rjbs
On today's PSC call, we were discussing the state of the "use v5.36" bundle, and whether it should turn off the "indirect" and "multidimensional" features. Our consensus was that this *should* happen. For those who want a refresher:
"no feature 'indirect'" disables "indirect object syntax" meaning you can no longer write this:
my $object = new Class (1, 2);
This is useful as a footgun remover, converting a mistake from runtime to compile time. For example, say you're like me and often forget to load Try::Tiny…
dinah:~$ perl -c -e 'try {1 };'
-e syntax OK
dinah:~$ perl -e 'try {1 };'
Can't locate object method "try" via package "1" (perhaps you forgot to load "1"?) at -e line 1.
dinah:~$ perl -c -e 'no feature "indirect"; try {1 };'
syntax error at -e line 1, near "try {"
-e had compilation errors.
The first two stanzas show the current behavior: the code compiles but won't run.
The third shows the behavior without indirect: it fails to compile.
This syntax has long been discouraged. Existing code will continue to work, and this will only affect code that disables the syntax. Some example code in documentation may now be "wrong" when put into place with use v5.36.0 in place, but that's a risk we're already taking with other features.
My take: indirect syntax will be around more or less forever.
"no feature 'multidimensional'" turns off the weird behavior of hash subscripting on lists as keys. What? It means this:
# These two lookups are effectively identical:
$hash{ 1,2,3 }
$hash{ join "$;", 1, 2, 3 }
Why? Historical reasons. It's neat, I've used it. But it's easy to simulate by other means, and mostly seems to show up as a footgun. This won't break existing code, because it will require opting-in.
My take: someday we might deprecate this behavior, but not this year anyway!
--
rjbs