Mailing List Archive

v5.36, indirect, and multidimensional
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
Re: v5.36, indirect, and multidimensional [ In reply to ]
2021-10-9 4:26 Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:

> 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
>

1. "no feature 'indirect'"

Personally it is ok that indirect syntax becomes disable by use v5.36, if
indirect syntax itself is not removed.

2. "no feature 'multidimensional'"

It is ok.
Re: v5.36, indirect, and multidimensional [ In reply to ]
Got it. Thanks a bunch!  —-Bill


Sent from Yahoo Mail for iPhone


On Friday, October 8, 2021, 11:37 PM, Yuki Kimoto <kimoto.yuki@gmail.com> wrote:


2021-10-9 4:26 Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:

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

1. "no feature 'indirect'"
Personally it is ok that indirect syntax becomes disable by use v5.36, if indirect syntax itself is not removed.
2. "no feature 'multidimensional'" 
It is ok. 
Re: v5.36, indirect, and multidimensional [ In reply to ]
On Fri, 08 Oct 2021 21:24:03 +0200, Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:

> 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.

Yes please, and thank you for considering it.

--
With regards,
Christian Walde
Re: v5.36, indirect, and multidimensional [ In reply to ]
Den 08.10.2021 21:24, skrev Ricardo Signes:
> 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.
>

+1 on removing default indirect support, but I hope we can alter the
current behaviour of 'no indirect' – as written in Neil Bower's Perl
Quirks document (whic isn't public anymore)

[quote]

Note that using 'no indirect' basically just is what one would expect
"use warnings 'indirect'" would've done.

I just realized I can't ensure all "indirect"-like syntax is treated as
function calls (or other fitting syntax), which was what I really
expected from the pragma/module.

Example code from a bug report I didn't submit now since I recalled the
"indirect" chapter here:

Expected output is a silent:

```
foo
bar
baz

```

```
$ cat /tmp/no_no_indirect.t

#!/usr/bin/env perl

use v5.30;
no indirect;

use Path::Tiny;

sub p {?
  say shift;
}

say Path::Tiny->new("foo");
p "bar";
p Path::Tiny->new("baz");
```

```
$ perl /tmp/no_no_indirect.t
Indirect call of method "p" on object "Path::Tiny" at
/tmp/no_no_indirect.t line 14.
foo
bar
Can't locate object method "p" via package "Path::Tiny" at
/tmp/no_no_indirect.t line 14.

``

[/quote]


--

Nicolas Mendoza
Re: v5.36, indirect, and multidimensional [ In reply to ]
On Mon, Oct 11, 2021 at 2:39 PM Nicolas Mendoza <mendoza@pvv.ntnu.no> wrote:
>
> Note that using 'no indirect' basically just is what one would expect "use warnings 'indirect'" would've done.
>
> I just realized I can't ensure all "indirect"-like syntax is treated as function calls (or other fitting syntax), which was what I really expected from the pragma/module.
>
> Example code from a bug report I didn't submit now since I recalled the "indirect" chapter here:
>
> Expected output is a silent:
>
> ```
> foo
> bar
> baz
>
> ```
>
> ```
> $ cat /tmp/no_no_indirect.t
>
> #!/usr/bin/env perl
>
> use v5.30;
> no indirect;
>
> use Path::Tiny;
>
> sub p {
> say shift;
> }
>
> say Path::Tiny->new("foo");
> p "bar";
> p Path::Tiny->new("baz");
> ```
>
> ```
> $ perl /tmp/no_no_indirect.t
> Indirect call of method "p" on object "Path::Tiny" at /tmp/no_no_indirect.t line 14.
> foo
> bar
> Can't locate object method "p" via package "Path::Tiny" at /tmp/no_no_indirect.t line 14.
>
> ``
>
> [/quote]

This is using the indirect CPAN module. I don't believe it is possible
for a CPAN module to impact the parsing enough to prevent any code
from being parsed as indirect, and can only do checks on the result.
The core feature "no feature 'indirect';" works as you desire. It is
unfortunate that these two have different behavior, but it seems
unavoidable.

It could be nice to have "use warnings 'indirect';" as a separate
addition. Being able to fail on indirect calls, rather than silently
treating them as function calls, can be valuable for writing code that
is meant to work on older perl versions.
Re: v5.36, indirect, and multidimensional [ In reply to ]
Den 11.10.2021 16:26, skrev Graham Knop:
> On Mon, Oct 11, 2021 at 2:39 PM Nicolas Mendoza <mendoza@pvv.ntnu.no> wrote:
>> Note that using 'no indirect' basically just is what one would expect "use warnings 'indirect'" would've done.
>>
>> I just realized I can't ensure all "indirect"-like syntax is treated as function calls (or other fitting syntax), which was what I really expected from the pragma/module.
>>
>> Example code from a bug report I didn't submit now since I recalled the "indirect" chapter here:
>> …
> This is using the indirect CPAN module. I don't believe it is possible
> for a CPAN module to impact the parsing enough to prevent any code
> from being parsed as indirect, and can only do checks on the result.
> The core feature "no feature 'indirect';" works as you desire.

That's really great to hear ;)

> It is
> unfortunate that these two have different behavior, but it seems
> unavoidable.
Fair enough.
> It could be nice to have "use warnings 'indirect';" as a separate
> addition. Being able to fail on indirect calls, rather than silently
> treating them as function calls, can be valuable for writing code that
> is meant to work on older perl versions.
>
Perhaps. On the other hand, either you want the code to be using
indirect notation, or you don't.

I guess it is only useful if you want the indirect feature to work, but
find possible problems that you might want to fix, specially when there
are collisions.

Not sure wether I would encourage the team to spend time adding that.
Collision issues has already been there all the time, I guess one of the
main reasons one wants to get rid of indirect notation.

One could argue that using function calls without parenthesis should be
discouraged though, so perhaps a more generic warning is more suitable.

--

Nicolas Mendoza
Re: v5.36, indirect, and multidimensional [ In reply to ]
On Fri, Oct 8, 2021, at 3:24 PM, Ricardo Signes wrote:
> 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.

I have filed https://github.com/Perl/perl5/pull/19184 and believe it is ready.

--
rjbs