From @cpansprout

I was trying to take advantage of the $; variable, writing code like this​:

$seen{@​$_{<type id>}}++

but it didn’t work. It was equivalent to $seen{$_->{id}}.

I looked at the code in op.c, and it adds the implicit join $; if the parameter is an OP_LIST. This means that this does what I wanted​:

$seen{(),@​$_{<type id>}}++

That can be very confusing.

But how should this be fixed? Or should this be fixed?

If we change it to imply join $; for slices, that would solve this particular case, but should these behave differently?

$seen{foo()}
$seen{(), foo()}

Flags​:
  category=core
  severity=low

Site configuration information for perl 5.17.6​:

Configured by sprout at Sat Nov 17 23​:09​:15 PST 2012.

Summary of my perl5 (revision 5 version 17 subversion 6) configuration​:
  Local Commit​: e1d8196c98d7cc6d34eedc83ba4193885673d43d
  Ancestor​: 10ffaf9
  Platform​:
  osname=darwin, osvers=10.5.0, archname=darwin-thread-multi-2level
  uname='darwin pint.local 10.5.0 darwin kernel version 10.5.0​: fri nov 5 23​:20​:39 pdt 2010; root​:xnu-1504.9.17~1release_i386 i386 '
  config_args='-de -DDEBUGGING -Duseithreads -Dusedevel -Accflags= -fcatch-undefined-behavior -DPERL_POISON'
  hint=recommended, useposix=true, d_sigaction=define
  useithreads=define, usemultiplicity=define
  useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
  use64bitint=undef, use64bitall=undef, uselongdouble=undef
  usemymalloc=n, bincompat5005=undef
  Compiler​:
  cc='gcc', ccflags ='-DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include',
  optimize='-O3 -g',
  cppflags='-DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
  ccversion='', gccversion='4.2.1 (Apple Inc. build 5664)', gccosandvers=''
  intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
  d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
  ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
  alignbytes=8, prototype=define
  Linker and Libraries​:
  ld='env MACOSX_DEPLOYMENT_TARGET=10.3 cc', ldflags =' -fstack-protector -L/usr/local/lib'
  libpth=/usr/local/lib /usr/lib
  libs=-ldbm -ldl -lm -lutil -lc
  perllibs=-ldl -lm -lutil -lc
  libc=, so=dylib, useshrplib=false, libperl=libperl.a
  gnulibc_version=''
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' '
  cccdlflags=' ', lddlflags=' -bundle -undefined dynamic_lookup -L/usr/local/lib -fstack-protector'

Locally applied patches​:
 

@​INC for perl 5.17.6​:
  /usr/local/lib/perl5/site_perl/5.17.6/darwin-thread-multi-2level
  /usr/local/lib/perl5/site_perl/5.17.6
  /usr/local/lib/perl5/5.17.6/darwin-thread-multi-2level
  /usr/local/lib/perl5/5.17.6
  /usr/local/lib/perl5/site_perl
  .

Environment for perl 5.17.6​:
  DYLD_LIBRARY_PATH (unset)
  HOME=/Users/sprout
  LANG=en_US.UTF-8
  LANGUAGE (unset)
  LD_LIBRARY_PATH (unset)
  LOGDIR (unset)
  PATH=/usr/bin​:/bin​:/usr/sbin​:/sbin​:/usr/local/bin​:/usr/X11/bin​:/usr/local/bin
  PERL_BADLANG (unset)
  SHELL=/bin/bash

From @davidnicol

On Sun, Nov 18, 2012 at 4​:42 PM, Father Chrysostomos <
perlbug-followup@​perl.org> wrote​:

I was trying to take advantage of the $; variable, writing code like this​:

$seen{@​$_{<type id>}}++

but it didn’t work. It was equivalent to $seen{$_->{id}}.

I looked at the code in op.c, and it adds the implicit join $; if the
parameter is an OP_LIST. This means that this does what I wanted​:

$seen{(),@​$_{<type id>}}++

That can be very confusing.

But how should this be fixed? Or should this be fixed?

If we change it to imply join $; for slices, that would solve this
particular case, but should these behave differently?

$seen{foo()}
$seen{(), foo()}

Yes, those should behave differently, and wantarray() within sub foo will
be false for
the first and true for the second.

As someone who uses $; often, I've found myself doing things like

  { my $listref = $_{<type id>};
  $seen{$$listref[0],$$listref[1],$$listref[2]}++ # join with $;
  }

regularly, after getting reminded about the syntactical requirement for a
list, not a slice, to trigger joining by $;.

In my opinion this is not a bug to fix, but rather a best practice to
debate (and maybe document.) The question is, what is the best way to
trigger $; join syntax?

Using an explicit intermediary is clearer for the maintainer, and moving
the trigger bar either up or down is sure to break things somewhere.

Prepending an empty list seems like an elegant way to listify an array; the
next time I need to implicitly join an array by $; I may use it instead of
expanding with a series of redundant subscripted terms.

  $seen{(),@​elements}++

seems more elegant than

  $seen{$elements[0],@​elements[1 .. $#elements]}++

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

From @mauke

On 26.11.2012 22​:35, David Nicol wrote​:

On Sun, Nov 18, 2012 at 4​:42 PM, Father Chrysostomos
<perlbug-followup@​perl.org <mailto​:perlbug-followup@​perl.org>> wrote​:

I was trying to take advantage of the $; variable\, writing code like
this​:

$seen\{@&#8203;$\_\{\<type id>\}\}\+\+

but it didn’t work\.  It was equivalent to $seen\{$\_\->\{id\}\}\.

I looked at the code in op\.c\, and it adds the implicit join $; if
the parameter is an OP\_LIST\.  This means that this does what I wanted&#8203;:

$seen\{\(\)\,@&#8203;$\_\{\<type id>\}\}\+\+

That can be very confusing\.

But how should this be fixed?  Or should this be fixed?

If we change it to imply join $; for slices\, that would solve this
particular case\, but should these behave differently?

$seen\{foo\(\)\}
$seen\{\(\)\, foo\(\)\}

Yes, those should behave differently, and wantarray() within sub foo
will be false for
the first and true for the second.

As someone who uses $; often, I've found myself doing things like

{ my $listref = $_{<type id>};
$seen{$$listref[0],$$listref[1],$$listref[2]}++ # join with $;
}

regularly, after getting reminded about the syntactical requirement for
a list, not a slice, to trigger joining by $;.

In my opinion this is not a bug to fix, but rather a best practice to
debate (and maybe document.) The question is, what is the best way to
trigger $; join syntax?

Using an explicit intermediary is clearer for the maintainer, and moving
the trigger bar either up or down is sure to break things somewhere.

If we're going for clarity/maintainability, how about $seen{join $;,
@​$ref}? (Also, there's no such thing as a list reference.)

--
Lukas Mai <l.mai@​web.de>

From zefram@fysh.org

We shouldn't change the rules for implicit $; usage. The current
behaviour is not a bug, and any tweak to the rules (short of eliminating
implicit $; entirely) would be just another set of rules to learn with
more Perl version portability problems. This ticket should be closed.

-zefram

From @xsawyerx

On Sun, 19 Nov 2017 01​:49​:50 -0800, zefram@​fysh.org wrote​:

We shouldn't change the rules for implicit $; usage. The current
behaviour is not a bug, and any tweak to the rules (short of eliminating
implicit $; entirely) would be just another set of rules to learn with
more Perl version portability problems. This ticket should be closed.

To be honest, I would already be weary of seeing implicit $; used. While we try to contract code as much as possible, this can be achieved in the current fashion is a short and readable way, as Mauke expressed, without using $; implicitly.

From @cpansprout

On Sun, 19 Nov 2017 06​:45​:28 -0800, xsawyerx@​cpan.org wrote​:

On Sun, 19 Nov 2017 01​:49​:50 -0800, zefram@​fysh.org wrote​:

We shouldn't change the rules for implicit $; usage. The current
behaviour is not a bug, and any tweak to the rules (short of
eliminating
implicit $; entirely) would be just another set of rules to learn
with
more Perl version portability problems. This ticket should be
closed.

To be honest, I would already be weary

If you don’t mind​: s/wea/lee/

of seeing implicit $; used.
While we try to contract code as much as possible, this can be
achieved in the current fashion is a short and readable way, as Mauke
expressed, without using $; implicitly.

I hope you are not proposing that this feature be removed. I have since gotten into the habit of writing ‘(),’ to force a list, and removing the feature will break my code.

--

Father Chrysostomos

From [Unknown Contact. See original ticket]

On Sun, 19 Nov 2017 06​:45​:28 -0800, xsawyerx@​cpan.org wrote​:

On Sun, 19 Nov 2017 01​:49​:50 -0800, zefram@​fysh.org wrote​:

We shouldn't change the rules for implicit $; usage. The current
behaviour is not a bug, and any tweak to the rules (short of
eliminating
implicit $; entirely) would be just another set of rules to learn
with
more Perl version portability problems. This ticket should be
closed.

To be honest, I would already be weary

If you don’t mind​: s/wea/lee/

of seeing implicit $; used.
While we try to contract code as much as possible, this can be
achieved in the current fashion is a short and readable way, as Mauke
expressed, without using $; implicitly.

I hope you are not proposing that this feature be removed. I have since gotten into the habit of writing ‘(),’ to force a list, and removing the feature will break my code.

--

Father Chrysostomos

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

From @cpansprout

On Sun, 19 Nov 2017 12​:33​:50 -0800, sprout wrote​:

On Sun, 19 Nov 2017 06​:45​:28 -0800, xsawyerx@​cpan.org wrote​:

On Sun, 19 Nov 2017 01​:49​:50 -0800, zefram@​fysh.org wrote​:

We shouldn't change the rules for implicit $; usage. The current
behaviour is not a bug, and any tweak to the rules (short of
eliminating
implicit $; entirely) would be just another set of rules to learn
with
more Perl version portability problems. This ticket should be
closed.

To be honest, I would already be weary

If you don’t mind​: s/wea/lee/

Or​: wary

--

Father Chrysostomos

From [Unknown Contact. See original ticket]

On Sun, 19 Nov 2017 12​:33​:50 -0800, sprout wrote​:

On Sun, 19 Nov 2017 06​:45​:28 -0800, xsawyerx@​cpan.org wrote​:

On Sun, 19 Nov 2017 01​:49​:50 -0800, zefram@​fysh.org wrote​:

We shouldn't change the rules for implicit $; usage. The current
behaviour is not a bug, and any tweak to the rules (short of
eliminating
implicit $; entirely) would be just another set of rules to learn
with
more Perl version portability problems. This ticket should be
closed.

To be honest, I would already be weary

If you don’t mind​: s/wea/lee/

Or​: wary

--

Father Chrysostomos

From @xsawyerx

On 11/19/2017 09​:33 PM, Father Chrysostomos via RT wrote​:

On Sun, 19 Nov 2017 06​:45​:28 -0800, xsawyerx@​cpan.org wrote​:

On Sun, 19 Nov 2017 01​:49​:50 -0800, zefram@​fysh.org wrote​:

We shouldn't change the rules for implicit $; usage. The current
behaviour is not a bug, and any tweak to the rules (short of
eliminating
implicit $; entirely) would be just another set of rules to learn
with
more Perl version portability problems. This ticket should be
closed.
To be honest, I would already be weary
If you don’t mind​: s/wea/lee/

Meant "wary," but "leery" will do as well. Sorry.
(I'm still learning this language, mind you. :)

of seeing implicit $; used.
While we try to contract code as much as possible, this can be
achieved in the current fashion is a short and readable way, as Mauke
expressed, without using $; implicitly.
I hope you are not proposing that this feature be removed.

Not at all, but this ticket suggested also extending $; for slices to be
able to avoid the "(), ..." pattern, right? That is what I was referring
to that I'm not overtly in favor of extending.