Closed p5pRT closed 11 years ago
p5pRT
commented
12 years ago $ perl -E'"abc" =~ /(b)/; say "@+"' 2 2
$ perl -E'@_ = qw( a b c ); say "@_"' a b c
$ perl -E'@. = qw( a b c ); say "@."' @.
$ perl -E'@. = qw( a b c ); say "@{.}"' a b c
What's up with #3?
- Eric
p5pRT
commented
12 years ago On Fri Jun 22 12:57:15 2012\, ikegami@adaelis.com wrote:
$ perl -E'"abc" =~ /(b)/; say "@+"' 2 2
$ perl -E'@_ = qw( a b c ); say "@_"' a b c
$ perl -E'@. = qw( a b c ); say "@."' @.
$ perl -E'@. = qw( a b c ); say "@{.}"' a b c
What's up with #3?
toke.c special-cases certain punct vars. Without thinking about this in detail\, my gut feeling is that allowing "@." will open up a can of worms.
Also\, there may be people wholly unintentionally relying on this. I know many times I’ve forgotten to escape my @’s and wondered why they were disappearing.
--
Father Chrysostomos
p5pRT
commented
12 years ago The RT System itself - Status changed from 'new' to 'open'
p5pRT
commented
12 years ago On Fri\, Jun 22\, 2012 at 4:08 PM\, Father Chrysostomos via RT \< perlbug-followup@perl.org> wrote:
Also\, there may be people wholly unintentionally relying on this. I know many times I’ve forgotten to escape my @’s and wondered why they were disappearing.
That's an argument for a warning\, seems to me. ("Possible unintended interpolation of reserved punctuation variable")
p5pRT
commented
12 years ago On Fri Jun 22 13:08:13 2012\, sprout wrote:
On Fri Jun 22 12:57:15 2012\, ikegami@adaelis.com wrote:
$ perl -E'"abc" =~ /(b)/; say "@+"' 2 2
$ perl -E'@_ = qw( a b c ); say "@_"' a b c
$ perl -E'@. = qw( a b c ); say "@."' @.
$ perl -E'@. = qw( a b c ); say "@{.}"' a b c
What's up with #3?
toke.c special-cases certain punct vars. Without thinking about this in detail\, my gut feeling is that allowing "@." will open up a can of worms.
Also\, there may be people wholly unintentionally relying on this. I know many times I’ve forgotten to escape my @’s and wondered why they were disappearing.
Are you saying this is a documentation bug?
p5pRT
commented
12 years ago "Eric Brine" (via RT) \perlbug\-followup@​perl\.org wrote on Fri\, 22 Jun 2012 12:57:15 PDT:
$ perl -E'"abc" =~ /(b)/; say "@+"' 2 2
$ perl -E'@_ = qw( a b c ); say "@_"' a b c
$ perl -E'@. = qw( a b c ); say "@."' @.
$ perl -E'@. = qw( a b c ); say "@{.}"' a b c
What's up with #3?
What's up with *#4*? How in the world is dot a legal name inside braces without quotes around it?
--tom
p5pRT
commented
12 years ago On Fri Jun 22 14:59:35 2012\, ikegami@adaelis.com wrote:
On Fri Jun 22 13:08:13 2012\, sprout wrote:
On Fri Jun 22 12:57:15 2012\, ikegami@adaelis.com wrote:
$ perl -E'"abc" =~ /(b)/; say "@+"' 2 2
$ perl -E'@_ = qw( a b c ); say "@_"' a b c
$ perl -E'@. = qw( a b c ); say "@."' @.
$ perl -E'@. = qw( a b c ); say "@{.}"' a b c
What's up with #3?
toke.c special-cases certain punct vars. Without thinking about this in detail\, my gut feeling is that allowing "@." will open up a can of worms.
Also\, there may be people wholly unintentionally relying on this. I know many times I’ve forgotten to escape my @’s and wondered why they were disappearing.
Are you saying this is a documentation bug?
No\, but the repercussions of that sort of change worry me. Maybe I just need to think it through more.
--
Father Chrysostomos
p5pRT
commented
12 years ago On Fri\, Jun 22\, 2012 at 7:55 PM\, Tom Christiansen \tchrist@​perl\.com wrote:
$ perl -E'@. = qw( a b c ); say "@{.}"'
abc
What's up with *#4*? How in the world is dot a legal name inside braces without quotes around it?
This isn't a dereference\, this is Perl's interpolation delimiter.
That's why C\<\< "${foo}" >> is allowed with strict on. That's why C\<\< "${Mod::foo}" >> is allowed. That's why C\<\< "${.}" >> is allowed.
perl -wE"use strict; my $foo=123; say qq{${foo}x} 123x perl -wE"use strict; our $foo=123; say qq{${main::foo}x} 123x perl -wE"use strict; say qq{${$}x} 5884x
Whoa\, it's also allowed outside of a literal!
perl -wE"use strict; my $foo=123; say ${foo} 123 perl -wE"use strict; our $foo=123; say ${main::foo} 123 perl -wE"use strict; say ${$} 5884
p5pRT
commented
12 years ago On Fri Jun 22 17:51:37 2012\, sprout wrote:
On Fri Jun 22 14:59:35 2012\, ikegami@adaelis.com wrote:
On Fri Jun 22 13:08:13 2012\, sprout wrote:
On Fri Jun 22 12:57:15 2012\, ikegami@adaelis.com wrote: .... Also\, there may be people wholly unintentionally relying on this. I know many times I’ve forgotten to escape my @’s and wondered why they were disappearing.
Are you saying this is a documentation bug?
No\, but the repercussions of that sort of change worry me. Maybe I just need to think it through more.
How about adding ``(W deprecated\, ambiguous) Reserved variable %s will someday interpolate'' to 5.16.x whenever an unused punct variable plausibly should have interpolated?
If the behavior is later correcte^Wchanged so that unused\, reserved variables do interpolate\, it'd be charitable to replace that with a new warning: ``(W ambiguous) Possible unintended interpolation of reserved variable %s''
p5pRT
commented
12 years ago On Tue Jul 03 11:43:08 2012\, pilcrow wrote:
On Fri Jun 22 17:51:37 2012\, sprout wrote:
On Fri Jun 22 14:59:35 2012\, ikegami@adaelis.com wrote:
On Fri Jun 22 13:08:13 2012\, sprout wrote:
On Fri Jun 22 12:57:15 2012\, ikegami@adaelis.com wrote: .... Also\, there may be people wholly unintentionally relying on this. I know many times I’ve forgotten to escape my @’s and wondered why they were disappearing.
Are you saying this is a documentation bug?
No\, but the repercussions of that sort of change worry me. Maybe I just need to think it through more.
How about adding ``(W deprecated\, ambiguous) Reserved variable %s will someday interpolate'' to 5.16.x whenever an unused punct variable plausibly should have interpolated?
If the behavior is later correcte^Wchanged so that unused\, reserved variables do interpolate\, it'd be charitable to replace that with a new warning: ``(W ambiguous) Possible unintended interpolation of reserved variable %s''
Neither of those possibilities makes me feel uneasy.
--
Father Chrysostomos
p5pRT
commented
11 years ago On Tue Jul 03 13:31:50 2012\, sprout wrote:
On Tue Jul 03 11:43:08 2012\, pilcrow wrote:
On Fri Jun 22 17:51:37 2012\, sprout wrote:
On Fri Jun 22 14:59:35 2012\, ikegami@adaelis.com wrote:
On Fri Jun 22 13:08:13 2012\, sprout wrote:
On Fri Jun 22 12:57:15 2012\, ikegami@adaelis.com wrote: .... Also\, there may be people wholly unintentionally relying on this. I know many times I’ve forgotten to escape my @’s and wondered why they were disappearing.
Are you saying this is a documentation bug?
No\, but the repercussions of that sort of change worry me. Maybe I just need to think it through more.
How about adding ``(W deprecated\, ambiguous) Reserved variable %s will someday interpolate'' to 5.16.x whenever an unused punct variable plausibly should have interpolated?
If the behavior is later correcte^Wchanged so that unused\, reserved variables do interpolate\, it'd be charitable to replace that with a new warning: ``(W ambiguous) Possible unintended interpolation of reserved variable %s''
Neither of those possibilities makes me feel uneasy.
ikegami\, sprout:
Do you have any recommendations (warnings? doc patches?) that can help us bring this RT to resolution?
Thank you very much. Jim Keenan
p5pRT
commented
11 years ago On Mon Jun 17 17:50:17 2013\, jkeenan wrote:
On Tue Jul 03 13:31:50 2012\, sprout wrote:
On Tue Jul 03 11:43:08 2012\, pilcrow wrote:
On Fri Jun 22 17:51:37 2012\, sprout wrote:
On Fri Jun 22 14:59:35 2012\, ikegami@adaelis.com wrote:
On Fri Jun 22 13:08:13 2012\, sprout wrote:
On Fri Jun 22 12:57:15 2012\, ikegami@adaelis.com wrote: .... Also\, there may be people wholly unintentionally relying on this. I know many times I’ve forgotten to escape my @’s and wondered why they were disappearing.
Are you saying this is a documentation bug?
No\, but the repercussions of that sort of change worry me. Maybe I just need to think it through more.
How about adding ``(W deprecated\, ambiguous) Reserved variable %s will someday interpolate'' to 5.16.x whenever an unused punct variable plausibly should have interpolated?
If the behavior is later correcte^Wchanged so that unused\, reserved variables do interpolate\, it'd be charitable to replace that with a new warning: ``(W ambiguous) Possible unintended interpolation of reserved variable %s''
Neither of those possibilities makes me feel uneasy.
ikegami\, sprout:
Do you have any recommendations (warnings? doc patches?) that can help us bring this RT to resolution?
If we don’t make any change here\, I don’t think we need a doc patch.
As for which warning should be added (and whether "@." should interpolate)\, I don’t know. I would be interested to hear what Ricardo thinks.
--
Father Chrysostomos
p5pRT
commented
11 years ago On Mon\, Jun 17\, 2013 at 8:50 PM\, James E Keenan via RT \< perlbug-followup@perl.org> wrote:
ikegami\, sprout:
Do you have any recommendations (warnings? doc patches?) that can help us bring this RT to resolution?
perlop says:
---BEGIN-- "Punctuation" arrays such as @* are usually interpolated only if the name is enclosed in braces @{*}\, but the arrays @_ \, @+ \, and @- are interpolated even without braces. ---END--
So the current behaviour is covered by the current docs\, and it's surely intentional behaviour designed to reduce errors. I'm ok with that.
For the curious\, the relevant section of toke.c is:
/* check for embedded arrays (@foo\, @::foo\, @'foo\, @{foo}\, @$foo\, @+\, @-) */ else if (*s == '@' && s[1]) { if (isWORDCHAR_lazy_if(s+1\,UTF)) break; if (strchr(":'{$"\, s[1])) break; if (!PL_lex_inpat && (s[1] == '+' || s[1] == '-')) break; /* in regexp\, neither @+ nor @- are interpolated */ }
- Eric
p5pRT
commented
11 years ago I agree with the assessment: this is documented\, the reasoning (avoid bizarre errors) seems sound\, and there is no bug here.
-- rjbs
p5pRT
commented
11 years ago I agree with the assessment: this is documented\, the reasoning (avoid bizarre errors) seems sound\, and there is no bug here.
-- rjbs
p5pRT
commented
11 years ago @rjbs - Status changed from 'open' to 'rejected'
Migrated from rt.perl.org#113792 (status was 'rejected')
Searchable as RT113792$