useless forbidding of list init of state vars?

p5pRT commented 11 years ago

Migrated from rt.perl.org#116789 (status was 'rejected')

Searchable as RT116789$

p5pRT commented 11 years ago

From perl-diddler@tlinx.org

Created by perl-diddler@tlinx.org

I don't understand the rational for disallowing list initialization of state vars:

perl -wE 'use strict; sub cntdn(){state ($x\,$y)=(3\,3); [$x--\, $y--]} use P; P "%s"\, cntdn for (1 .. 3)' Initialization of state variables in list context currently forbidden at -e line 2\, near ");" Initialization of state variables in list context currently forbidden at -e line 2\, near ");" BEGIN not safe after errors--compilation aborted at -e line 3.

Isn't it the case that you only want them initialized\, 'once' during "START'/BEGIN time?

If so\, thats fairly trivial to do in a ugly way:

perl -wE 'use strict;BEGIN{$::INC{"I.pm"}=1} sub cntdn() { state ($x\,$y);use I(($x\,$y)=(3\,3)); [$x--\, $y--]} use P; P "%s"\, cntdn for (1 .. 3)' [3\,3] [2\,2] [1\,1] ---- Assumming I understood the problem. Does the above\, semantically\, fit the bill for initializing state vars only once\, at 'load time'? Wouldn't it be possible to come up with something syntactically more attractive if you worked inside the parser?

(If only Perl had a '#define/macro' ability...)

Perl Info

``` Flags: category=core severity=wishlist This perlbug was built using Perl 5.16.1 - Mon Sep 10 13:51:31 UTC 2012 It is being executed now by Perl 5.16.1 - Mon Sep 10 13:45:59 UTC 2012. Site configuration information for perl 5.16.1: Configured by abuild at Mon Sep 10 13:45:59 UTC 2012. Summary of my perl5 (revision 5 version 16 subversion 1) configuration: Platform: osname=linux, osvers=3.4.6-2.10-default, archname=x86_64-linux-thread-multi uname='linux build35 3.4.6-2.10-default #1 smp thu jul 26 09:36:26 utc 2012 (641c197) x86_64 x86_64 x86_64 gnulinux ' config_args='-ds -e -Dprefix=/usr -Dvendorprefix=/usr -Dinstallusrbinperl -Dusethreads -Di_db -Di_dbm -Di_ndbm -Di_gdbm -Dd_dbm_open -Duseshrplib=true -Doptimize=-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -Wall -pipe -Accflags=-DPERL_USE_SAFE_PUTENV -Dotherlibdirs=/usr/lib/perl5/site_perl' hint=recommended, useposix=true, d_sigaction=define useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=define, use64bitall=define, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -fstack-protector -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -Wall -pipe', cppflags='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -fstack-protector' ccversion='', gccversion='4.7.1 20120723 [gcc-4_7-branch revision 189773]', gccosandvers='' intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib64 -fstack-protector' libpth=/lib64 /usr/lib64 /usr/local/lib64 libs=-lm -ldl -lcrypt -lpthread perllibs=-lm -ldl -lcrypt -lpthread libc=/lib64/libc-2.16.so, so=so, useshrplib=true, libperl=libperl.so gnulibc_version='2.16' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/usr/lib/perl5/5.16.1/x86_64-linux-thread-multi/CORE' cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib64 -fstack-protector' Locally applied patches: @INC for perl 5.16.1: /home/law/bin/lib /usr/lib/perl5/site_perl/5.16.1/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.16.1 /usr/lib/perl5/vendor_perl/5.16.1/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.16.1 /usr/lib/perl5/5.16.1/x86_64-linux-thread-multi /usr/lib/perl5/5.16.1 /usr/lib/perl5/site_perl/5.16.1/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.16.1 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.16.0/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.16.0 /usr/lib/perl5/vendor_perl /usr/lib/perl5/site_perl . Environment for perl 5.16.1: HOME=/home/law LANG=en_US.UTF-8 LANGUAGE (unset) LC_COLLATE=C LC_CTYPE=en_US.UTF-8 LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=.:/sbin:/usr/local/sbin:/home/law/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/opt/kde3/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin:/opt/dell/srvadmin/bin:/usr/sbin:/etc/local/func_lib:/home/law/lib:/home/law/bin/lib PERL5OPT=-CSA -I/home/law/bin/lib PERL_BADLANG (unset) SHELL=/bin/bash ```

p5pRT commented 11 years ago

From @jkeenan

On Sat Feb 16 15:24:29 2013\, LAWalsh wrote:

This is a bug report for perl from perl-diddler@tlinx.org\, generated with the help of perlbug 1.39 running under perl 5.16.1.

----------------------------------------------------------------- [Please describe your issue here] I don't understand the rational for disallowing list initialization of state vars:

perl -wE 'use strict; sub cntdn(){state ($x\,$y)=(3\,3); [$x--\, $y--]} use P; P "%s"\, cntdn for (1 .. 3)' Initialization of state variables in list context currently forbidden at -e line 2\, near ");" Initialization of state variables in list context currently forbidden at -e line 2\, near ");" BEGIN not safe after errors--compilation aborted at -e line 3.

Here's what pod/perldiag.pod (blead) says about this:

########## Initialization of state variables in list context currently forbidden (F) Currently the implementation of "state" only permits the initialization of scalar variables in scalar context. Re-write "state ($a) = 42" as "state $a = 42" to change from list to scalar context. Constructions such as "state (@a) = foo()" will be supported in a future perl release. ##########

So\, while there may be a more specific rationale\, the immediate reason is: It hasn't been done yet. Would you care to supply a patch?

Isn't it the case that you only want them initialized\, 'once' during "START'/BEGIN time?

Please see the documentation in pod/perlsub.pod under the heading\, "Persistent variables via state()". You will note that there's no discussion of "START" time (whatever that might be) or BEGIN time.

If so\, thats fairly trivial to do in a ugly way:

perl -wE 'use strict;BEGIN{$::INC{"I.pm"}=1} sub cntdn() { state ($x\,$y);use I(($x\,$y)=(3\,3)); [$x--\, $y--]} use P; P "%s"\, cntdn for (1 .. 3)' [3\,3] [2\,2] [1\,1] ---- Assumming I understood the problem. Does the above\, semantically\, fit the bill for initializing state vars only once\, at 'load time'? Wouldn't it be possible to come up with something syntactically more attractive if you worked inside the parser?

(If only Perl had a '#define/macro' ability...)

Since the use of state variables is\, as indicated above\, not tied to any particular point in Perl's execution\, these questions are not relevant.

Thank you very much. Jim Keenan

p5pRT commented 11 years ago

The RT System itself - Status changed from 'new' to 'open'

p5pRT commented 11 years ago

From perl-diddler@tlinx.org

On Sat Feb 16 16:09:50 2013\, jkeenan wrote:

Please see the documentation in pod/perlsub.pod under the heading\, "Persistent variables via state()". You will note that there's no discussion of "START" time (whatever that might be) or BEGIN time.

See 'perlvar' $(^GLOBAL_PHASE} -- The current phase of the perl interpreter. CONSTRUCT... START This is the global compile-time. That includes\, basically\, every "BEGIN" block executed directly or indirectly from during the compile-time of the top- level program.

This phase is not called "BEGIN" to avoid confusion with "BEGIN"-blocks\, as those are executed during compile-time of any compilation unit\, not just the top- level program. A new\, localised compile-time entered at run-time\, for example by constructs as "eval "use SomeModule"" are not global interpreter phases\, and therefore aren't reflected by "${^GLOBAL_PHASE}".

The perlsub.pod you refer to says: When combined with variable declaration\, simple scalar assignment to "state" variables (as in "state $x = 42") is executed only the first time. When such statements are evaluated subsequent times\, the assignment is ignored. The behavior of this sort of assignment to non- scalar variables is undefined.

Which isn't really correct:

#!/usr/bin/perl -w use strict; sub sfx($) { use integer; use P; my $n=shift;my $x=$n%100; my $_; my %dt= qw(1 st 2 nd 3 rd) ; $n.(($_=$dt{$x%10}) && $x/10-1 ? $_:"th")} for my $iterator (1 .. 5) { eval { use feature "state"; local * gimme_another = sub {state $x; return ++$x }; printf "%s time: gimme_another=%d\n"\, sfx($iterator)\, &gimme_another }; die "$@" if $@; }

/tmp/testprog1.pl
1st time: gimme_another=1 2nd time: gimme_another=1 3rd time: gimme_another=1 4th time: gimme_another=1 5th time: gimme_another=1

As you can see\, it isn't just initialized the 1st time\, but start off at zero the 2nd\, 3rd\, 4th... etc time.

Would you like me to file a bug report on the doc page for you\, or do you want to file it?

Apparently from the perlvar section above\, the correct initialization is 'in a BEGIN' block whenever a section of code containing that block is 'compiled'.

I mentioned the first example\, above\, as I seem to remember the person who implemented state (who would be far more knowledgeable and more likely appropriate to make such a change\, if they wanted\, than I) saying that they had a hard time telling how to do list context initializations only during the correct "compiler phase". I thought it was START time\, as I vaguely remember (2nd hand) Larry saying that it was to be like a BSS section in the binary of a C program -- an area that was loaded initially with static values at load time. Which\, in my 1st example\, could be checked for by also checking GLOBAL_PHASE before you did the assignment in the BEGIN section of the C\ statement.

So I'm not clear what was intended and could think of uses for both behaviors so that's something that would need some discussion which ... well... is difficult for me to participate in for multiple reasons (Pavlovian responses\, accessibility...etc)..

My example was a hope to stimulate the "aha" processes of the person who was having problems implementing it -- I didn't know if such an example might stimulate a new way of thinking about the problem.

But now ... at the very least the perlsub page you point out is flawed. Did it mean 'BEGIN' blocks\, or START-time?

p5pRT commented 11 years ago

From @ikegami

On Sat\, Feb 16\, 2013 at 10:48 PM\, Linda Walsh via RT \< perlbug-followup@perl.org> wrote:

As you can see\, it isn't just initialized the 1st time\, but start off at zero the 2nd\, 3rd\, 4th... etc time.

You show that each $x is initialised the first time C\ is executed\, just like the docs say.

Contrary to your claims\, you didn't show any $x being initialised the on subsequent executions of C\ since you never called any of the subs more than once.

Would you like me to file a bug report on the doc page for you\, or do you want to file it?

You haven't demonstrated any bug.

- Eric

p5pRT commented 11 years ago

From perl-diddler@tlinx.org

On Sat Feb 16 22:44:33 2013\, ikegami@adaelis.com wrote:

On Sat\, Feb 16\, 2013 at 10:48 PM\, Linda Walsh via RT \< perlbug-followup@perl.org> wrote:

As you can see\, it isn't just initialized the 1st time\, but start off at zero the 2nd\, 3rd\, 4th... etc time.

You show that each $x is initialised the first time C\ is executed\, just like the docs say.

I *eval*ate the same code 5 times and the variable is is re-initialized each time -- it doesn't hold it's value.

Then it says "when such statements are **eval**uated subsequent times\, the assignment is ignored.

The document is equating execution and evaluation.

Contrary to your claims\, you didn't show any $x being initialised the on subsequent executions of C\ since you never called any of the subs more than once.

"gimme_another"\, also the name of the subroutine that is called multiple times in the perlsub.pod is called 5 times here. It is the subroutine that has the state var in it. The manpage clearly says on subsequent evaluations it shouldn't be reinitialized.

p5pRT commented 11 years ago

From @ikegami

On Sun\, Feb 17\, 2013 at 3:41 AM\, Linda Walsh via RT \< perlbug-followup@perl.org> wrote:

On Sat Feb 16 22:44:33 2013\, ikegami@adaelis.com wrote:

On Sat\, Feb 16\, 2013 at 10:48 PM\, Linda Walsh via RT \< perlbug-followup@perl.org> wrote:

As you can see\, it isn't just initialized the 1st time\, but start off at zero the 2nd\, 3rd\, 4th... etc time.

You show that each $x is initialised the first time C\ is executed\, just like the docs say.

I *eval*ate the same code 5 times and the variable is is re-initialized each time -- it doesn't hold it's value.

Remove C\ and you'll get the same result. C\ has nothing to do with why you get the same output five times.

I shall repeat: You creates 5 subs with a lexical var named $x\, and each got initialised once.

p5pRT commented 11 years ago

From @ikegami

On Sun\, Feb 17\, 2013 at 4:22 AM\, Eric Brine \ikegami@adaelis\.com wrote:

On Sun\, Feb 17\, 2013 at 3:41 AM\, Linda Walsh via RT \< perlbug-followup@perl.org> wrote:

On Sat Feb 16 22:44:33 2013\, ikegami@adaelis.com wrote:

On Sat\, Feb 16\, 2013 at 10:48 PM\, Linda Walsh via RT \< perlbug-followup@perl.org> wrote:

As you can see\, it isn't just initialized the 1st time\, but start off at zero the 2nd\, 3rd\, 4th... etc time.

You show that each $x is initialised the first time C\ is executed\, just like the docs say.

I *eval*ate the same code 5 times and the variable is is re-initialized each time -- it doesn't hold it's value.

Remove C\ and you'll get the same result. C\ has nothing to do with why you get the same output five times.

I shall repeat: You created 5 subs with a lexical var named $x\, and each got initialised once.

Perhaps you should stop creating demonstrations so complicated you have problems understanding them.

# Two state vars\, initialised once each.

perl -E"for (1..2) { local *f = sub { state $x; ++$x }; say f(); }" 1 1

# One state var\, initialised once.

perl -E"for (1..2) { state $x; local *f = sub { ++$x }; say f(); }" 1 2

p5pRT commented 11 years ago

From perl-diddler@tlinx.org

On Sun Feb 17 01:23:36 2013\, ikegami@adaelis.com wrote:

Remove C\ and you'll get the same result. C\ has nothing to do with why you get the same output five times.

I shall repeat: You creates 5 subs with a lexical var named $x\, and each got initialised once.

Ok\, fine.. you're right.

The documentation is just perfect clear the way it is.

That doesn't negate the subject of this RFE\, which is clearly not supported at this time. If only you could so eagerly prove to me that worked\, then you'd be awesome.

p5pRT commented 11 years ago

From @jkeenan

On Sun Feb 17 04:45:33 2013\, LAWalsh wrote:

On Sun Feb 17 01:23:36 2013\, ikegami@adaelis.com wrote:

Remove C\ and you'll get the same result. C\ has nothing to do with why you get the same output five times.

I shall repeat: You creates 5 subs with a lexical var named $x\, and each got initialised once. ---- Ok\, fine.. you're right.

The documentation is just perfect clear the way it is.

That doesn't negate the subject of this RFE\, which is clearly not supported at this time. If only you could so eagerly prove to me that worked\, then you'd be awesome.

p5pRT commented 11 years ago

@jkeenan - Status changed from 'open' to 'rejected'

p5pRT commented 11 years ago

From @demerphq

On 17 February 2013 13:45\, Linda Walsh via RT \perlbug\-followup@perl\.org wrote:

On Sun Feb 17 01:23:36 2013\, ikegami@adaelis.com wrote:

Remove C\ and you'll get the same result. C\ has nothing to do with why you get the same output five times.

I shall repeat: You creates 5 subs with a lexical var named $x\, and each got initialised once. ---- Ok\, fine.. you're right.

The documentation is just perfect clear the way it is.

That doesn't negate the subject of this RFE\, which is clearly not supported at this time. If only you could so eagerly prove to me that worked\, then you'd be awesome.

You really should read more carefully\, as if you had you would know he said that the reason it does not work is purely because no-one has had time or interest to implement the feature\, and that patches to implement it are welcome.

Yves

-- perl -Mre=debug -e "/just|another|perl|hacker/"

p5pRT commented 11 years ago

From @ikegami

On Sun\, Feb 17\, 2013 at 7:45 AM\, Linda Walsh via RT \< perlbug-followup@perl.org> wrote:

On Sun Feb 17 01:23:36 2013\, ikegami@adaelis.com wrote:

Remove C\ and you'll get the same result. C\ has nothing to do with why you get the same output five times.

I shall repeat: You creates 5 subs with a lexical var named $x\, and each got initialised once. ---- Ok\, fine.. you're right.

The documentation is just perfect clear the way it is.

I think you might have meant to be sarcastic\, but actually\, it is. It's not appropriate to go into detail about a corner case that affects high-level coders that can understand what's happening and how to work around it.

p5pRT commented 11 years ago

From @khwilliamson

On 02/17/2013 02:25 PM\, Eric Brine wrote:

On Sun\, Feb 17\, 2013 at 7:45 AM\, Linda Walsh via RT \<perlbug-followup@perl.org \mailto:perlbug\-followup@perl\.org> wrote:
On Sun Feb 17 01&#8203;:23&#8203;:36 2013\, ikegami@&#8203;adaelis\.com
\<mailto&#8203;:ikegami@&#8203;adaelis\.com> wrote&#8203;:
 > Remove C\<eval> and you'll get the same result\. C\<eval> has
nothing to do
 > with why you get the same output five times\.
 >
 > I shall repeat&#8203;: You creates 5 subs with a lexical var named $x\,
and each
 > got initialised once\.
\-\-\-\-
Ok\, fine\.\. you're right\.

The documentation is just perfect clear the way it is\.
I think you might have meant to be sarcastic\, but actually\, it is. It's not appropriate to go into detail about a corner case that affects high-level coders that can understand what's happening and how to work around it.

Just a note\, sarcasm does not translate well\, and should be avoided if at all possible for even very intelligent people whose native language is different then the joke is being expressed in.

p5pRT commented 11 years ago

From perl-diddler@tlinx.org

On Sun Feb 17 13:26:12 2013\, ikegami@adaelis.com wrote:

On Sun\, Feb 17\, 2013 at 7:45 AM\, Linda Walsh via RT \<

Ok\, fine.. you're right.

The documentation is just perfect clear the way it is

I think you might have meant to be sarcastic\, but actually\, it is. It's not appropriate to go into detail about a corner case that affects high-level coders that can understand what's happening and how to work around it.

Glad to hear you are the official litmus test of understanding for all perl users! If you think it's fine\, it must be.

I'm sure no one might get the idea that C\ vars might only be executed once / program run (like C\'s) vs. once/evaluation (despite the pod saying that it won't be reinitialized on subsequent evaluations.

I shall repeat: You creates 5 subs with a lexical var named $x\, and each got initialised once.

you were right... fixed that. I still wonder if state was meant to be a private var executed only once / program run vs./eval (difference demoed below. It's good that the wording on the perlsub page makes the difference clear to perl experts...I hope no one new to perl\, coming from 'C' will read that page\, and find out their expectations were incorrect. NOT that they can't work around it. That's trivial.

Understanding what the design intent was and being able to use the docs to get it right the first time\, vs. discovering it's not what they thought and "being able to easily work around it"\, to me\, feel like 2 different things.....but maybe to others\, that's not the case.

cat stateVstatic.pl #!/usr/bin/perl -w use 5.16.0; use P; sub sfx($) { use integer; my $n=shift;my $x=$n%100; my $_; my %dt= qw(1 st 2 nd 3 rd) ; $n.(($_=$dt{$x%10}) && $x/10-1 ? $_:"th")} for (my $i=0; $i\<5;++$i) { sub gimme_another() { {eval q[our $global_state++; state $eval_state++; { state_per_prog => $global_state\, state_per_eval => $eval_state}] }; } P "%s time: gimme_another=%s\n"\, sfx($i)\, gimme_another(); }

Ishtar:law/bin> stateVstatic.pl 0th time: gimme_another={"state_per_eval"=>"1"\, "state_per_prog"=>"1"} 1st time: gimme_another={"state_per_eval"=>"1"\, "state_per_prog"=>"2"} 2nd time: gimme_another={"state_per_eval"=>"1"\, "state_per_prog"=>"3"} 3rd time: gimme_another={"state_per_eval"=>"1"\, "state_per_prog"=>"4"} 4th time: gimme_another={"state_per_eval"=>"1"\, "state_per_prog"=>"5"}

p5pRT commented 11 years ago

From @Leont

On Sun\, Feb 17\, 2013 at 12:24 AM\, Linda Walsh \perlbug\-followup@perl\.org wrote:

I don't understand the rational for disallowing list initialization of state vars:

perl -wE 'use strict; sub cntdn(){state ($x\,$y)=(3\,3); [$x--\, $y--]} use P; P "%s"\, cntdn for (1 .. 3)' Initialization of state variables in list context currently forbidden at -e line 2\, near ");" Initialization of state variables in list context currently forbidden at -e line 2\, near ");" BEGIN not safe after errors--compilation aborted at -e line 3.

Hi Linda\,

Could you please not open a bug ticket every time you have a perl question? Specially when a simple 'use diagnostics' would have provided you the answer to your question. There are other more suitable platforms for that such as perlmonks and stackoverflow.

Leon

p5pRT commented 11 years ago

From perl-diddler@tlinx.org

On Sun Feb 17 05:26:38 2013\, demerphq wrote:

You really should read more carefully\, as if you had you would know he said that the reason it does not work is purely because no-one has had time or interest to implement the feature\, and that patches to implement it are welcome.

That's not what the person working on the feature said at the time they were working on it -- they said they said that there was something about the parser that they couldn't figure out how to do at the time\, so for now\, this was what we got.

Sometimes an RFE with a suggestion on a feature can stimulate someone to look at a problem in a different light that may let them solve the problem in a different way. At least I have found that to be the case at times\, personally.

=========== Leont politely asked:

Hi Linda\, Could you please not open a bug ticket every time you have a perl question? Specially when a simple 'use diagnostics' would have provided you the answer to your question. There are other more suitable platforms for that such as perlmonks and stackoverflow

It was after asking a question on perlmonks that was answered with a quote from the camel book that had me wondering why for(;;) wasn't supported as it was so easy (according the the camel book).

I understand now why perl developers haven't done that yet\, and have been told that I am welcome to provide a patch. It *IS* a limited use case\, I said that in the bug report\, just that it seems to contradict what was being quoted to me from the Camel book.

Filing a bug is not my first choice given the some of the personalities that have knee jerk reactions to me\, at this point -- primarily\, for my being overly attentive to details that others think are unimportant if they see them at all. A bit overfocused at times\, I am. Sorry\, I will admit to it -- it isn't out of any malice that it happens -- but most often because I *like* something.

;=(

p5pRT commented 11 years ago

From @nwc10

On Sun Feb 17 04:45:33 2013\, LAWalsh wrote:

On Sun Feb 17 01:23:36 2013\, ikegami@adaelis.com wrote:

Remove C\ and you'll get the same result. C\ has nothing to do with why you get the same output five times.

I shall repeat: You creates 5 subs with a lexical var named $x\, and each got initialised once. ---- Ok\, fine.. you're right.

The documentation is just perfect clear the way it is.

That doesn't negate the subject of this RFE\, which is clearly not supported at this time. If only you could so eagerly prove to me that worked\, then you'd be awesome.

Describing this as a "Request for Enhancement" *now* is somewhat contradicting the ticket's submitted subject of "useless forbidding of list init of state vars?"

The restriction is not useless. As Porting/todo.pod notes\, there are two forms of syntax that need to differ in behaviour\, and it's not obvious to anyone where to patch the code to tell them apart. Until that's possible\, we prefer to leave things as they were before\, instead of giving people the ability to write code which they may not realise is buggy\, and will break later.

Nicholas Clark

Perl / perl5