From @vanstyn

(After a report in clp.moderated from Peter Scott <peter@​psdt.com>.)

perl -Dr -we '(($y) = "x") =~ s/a/b/'

shows that a) perl is trying to perform the substitution on the string
'1' which is not what the caller intended, and b) '1' is not marked
readonly in this context, so no error is reported. I think both of
these are bugs​: I think the former should be fixed by giving an error
if the LHS of a binding operator is supplied as a list, and that the
latter should be fixed (if still relevant) by marking the count of
list elements as readonly.

Hugo

From @chorny

Same result on perl 5.14.0.

http​://rt.perl.org/rt3/Ticket/Display.html?id=4514

On Wed Oct 25 08​:41​:02 2000, hv@​crypt.compulink.co.uk wrote​:

(After a report in clp.moderated from Peter Scott <peter@​psdt.com>.)

perl -Dr -we '(($y) = "x") =~ s/a/b/'

shows that a) perl is trying to perform the substitution on the string
'1' which is not what the caller intended, and b) '1' is not marked
readonly in this context, so no error is reported. I think both of
these are bugs​: I think the former should be fixed by giving an error
if the LHS of a binding operator is supplied as a list, and that the
latter should be fixed (if still relevant) by marking the count of
list elements as readonly.

--
Alexandr Ciornii, http​://chorny.net

From [Unknown Contact. See original ticket]

Same result on perl 5.14.0.

http​://rt.perl.org/rt3/Ticket/Display.html?id=4514

On Wed Oct 25 08​:41​:02 2000, hv@​crypt.compulink.co.uk wrote​:

(After a report in clp.moderated from Peter Scott <peter@​psdt.com>.)

perl -Dr -we '(($y) = "x") =~ s/a/b/'

shows that a) perl is trying to perform the substitution on the string
'1' which is not what the caller intended, and b) '1' is not marked
readonly in this context, so no error is reported. I think both of
these are bugs​: I think the former should be fixed by giving an error
if the LHS of a binding operator is supplied as a list, and that the
latter should be fixed (if still relevant) by marking the count of
list elements as readonly.

--
Alexandr Ciornii, http​://chorny.net

From @jkeenan

On Fri Jun 10 00​:01​:29 2011, chorny wrote​:

Same result on perl 5.14.0.

http​://rt.perl.org/rt3/Ticket/Display.html?id=4514

On Wed Oct 25 08​:41​:02 2000, hv@​crypt.compulink.co.uk wrote​:

(After a report in clp.moderated from Peter Scott <peter@​psdt.com>.)

perl -Dr -we '(($y) = "x") =~ s/a/b/'

shows that a) perl is trying to perform the substitution on the string
'1' which is not what the caller intended, and b) '1' is not marked
readonly in this context, so no error is reported. I think both of
these are bugs​: I think the former should be fixed by giving an error
if the LHS of a binding operator is supplied as a list, and that the
latter should be fixed (if still relevant) by marking the count of
list elements as readonly.

This is what I got after doing a debugging build on blead​:

#####
./perl -Dr -we '(($y) = "x") =~ s/a/b/'
#####
Compiling REx "a"
rarest char a at 0
Final program​:
  1​: EXACT <a> (3)
  3​: END (0)
anchored "a" at 0 (checking anchored isall) minlen 1
Name "main​::y" used only once​: possible typo at -e line 1.
Enabling $` $&amp; $' support (0x7).

EXECUTING...

Matching REx "a" against "1"
Did not find anchored substr "a"...
Match rejected by optimizer
Freeing REx​: "a"
#####

$ ./perl -Ilib -V
Summary of my perl5 (revision 5 version 19 subversion 4) configuration​:
  Commit id​: 3a76eb2
  Platform​:
  osname=linux, osvers=2.6.32-358.el6.x86_64, archname=x86_64-linux
  uname='linux dromedary-001.ams6.corp.booking.com
2.6.32-358.el6.x86_64 #1 smp fri feb 22 00​:31​:26 utc 2013 x86_64 x86_64
x86_64 gnulinux '
  config_args='-des -Dusedevel -DDEBUGGING'
  hint=recommended, useposix=true, d_sigaction=define
  useithreads=undef, usemultiplicity=undef
  useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
  use64bitint=define, use64bitall=define, uselongdouble=undef
  usemymalloc=n, bincompat5005=undef
  Compiler​:
  cc='cc', ccflags ='-DDEBUGGING -fno-strict-aliasing -pipe
-fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64',
  optimize='-O2 -g',
  cppflags='-DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector
-I/usr/local/include'
  ccversion='', gccversion='4.4.7 20120313 (Red Hat 4.4.7-3)',
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 =' -fstack-protector -L/usr/local/lib'
  libpth=/usr/local/lib /lib/../lib64 /usr/lib/../lib64 /lib /usr/lib
/lib64 /usr/lib64 /usr/local/lib64
  libs=-lnsl -ldl -lm -lcrypt -lutil -lc
  perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
  libc=/lib/libc-2.12.so, so=so, useshrplib=false, libperl=libperl.a
  gnulibc_version='2.12'
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
  cccdlflags='-fPIC', lddlflags='-shared -O2 -g -L/usr/local/lib
-fstack-protector'

Characteristics of this binary (from libperl)​:
  Compile-time options​: DEBUGGING HAS_TIMES PERLIO_LAYERS
  PERL_DONT_CREATE_GVSV
  PERL_HASH_FUNC_ONE_AT_A_TIME_HARD PERL_MALLOC_WRAP
  PERL_NEW_COPY_ON_WRITE PERL_PRESERVE_IVUV
  PERL_USE_DEVEL USE_64_BIT_ALL USE_64_BIT_INT
  USE_LARGE_FILES USE_LOCALE USE_LOCALE_COLLATE
  USE_LOCALE_CTYPE USE_LOCALE_NUMERIC USE_PERLIO
  USE_PERL_ATOF
  Built under linux
  Compiled at Sep 7 2013 04​:19​:53
  %ENV​:
  PERLBREW_BASHRC_VERSION="0.63"
  PERLBREW_HOME="/home/jkeenan/.perlbrew"
  PERLBREW_ROOT="/home/jkeenan/perl5/perlbrew"
  @​INC​:
  lib
  /usr/local/lib/perl5/site_perl/5.19.4/x86_64-linux
  /usr/local/lib/perl5/site_perl/5.19.4
  /usr/local/lib/perl5/5.19.4/x86_64-linux
  /usr/local/lib/perl5/5.19.4
  /usr/local/lib/perl5/site_perl
  .

From @iabyn

On Fri, Sep 06, 2013 at 07​:24​:44PM -0700, James E Keenan via RT wrote​:

On Wed Oct 25 08​:41​:02 2000, hv@​crypt.compulink.co.uk wrote​:

(After a report in clp.moderated from Peter Scott <peter@​psdt.com>.)

perl -Dr -we '(($y) = "x") =~ s/a/b/'

shows that a) perl is trying to perform the substitution on the string
'1' which is not what the caller intended, and b) '1' is not marked
readonly in this context, so no error is reported. I think both of
these are bugs​: I think the former should be fixed by giving an error
if the LHS of a binding operator is supplied as a list, and that the
latter should be fixed (if still relevant) by marking the count of
list elements as readonly.

I don't think either of these are bugs.

In the first instance, its a list assignment evaluated in scalar context,
which is well-defined as returning the number of elements assigned.
The result may be slightly unexpected to the uninitiated, but its no
different than say

  $count = (($y) = "x");

which sets count to 1.

In the second instance, (($y) = "x") in scalar context is an expression
that returns a well-defined numeric value. I see no rationale for it
to be read-only, any more than any other expression should return a
read-only value.

--
In economics, the exam questions are the same every year.
They just change the answers.

From @cpansprout

On Sat Sep 07 02​:21​:21 2013, davem wrote​:

I don't think either of these are bugs.

I agree, and have rejected this ticket.

--

Father Chrysostomos

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

From @cpansprout

On Sat Sep 07 02​:21​:21 2013, davem wrote​:

On Fri, Sep 06, 2013 at 07​:24​:44PM -0700, James E Keenan via RT wrote​:

On Wed Oct 25 08​:41​:02 2000, hv@​crypt.compulink.co.uk wrote​:

(After a report in clp.moderated from Peter Scott <peter@​psdt.com>.)

perl -Dr -we '(($y) = "x") =~ s/a/b/'

shows that a) perl is trying to perform the substitution on the
string
'1' which is not what the caller intended, and b) '1' is not marked
readonly in this context, so no error is reported. I think both of
these are bugs​: I think the former should be fixed by giving an
error
if the LHS of a binding operator is supplied as a list, and that the
latter should be fixed (if still relevant) by marking the count of
list elements as readonly.

I don't think either of these are bugs.

In the first instance, its a list assignment evaluated in scalar context,
which is well-defined as returning the number of elements assigned.
The result may be slightly unexpected to the uninitiated, but its no
different than say

$count = \(\($y\) = "x"\);

which sets count to 1.

In the second instance, (($y) = "x") in scalar context is an expression
that returns a well-defined numeric value. I see no rationale for it
to be read-only, any more than any other expression should return a
read-only value.

Hmm, but should aassign be allowed as a scalar lvalue?

We also allow​:

read STDIN, @​a=qw(foo bar), 10

Should we?

(I wrote earlier that I agreed. Now I’m not sure. Reopening....)

--

Father Chrysostomos

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

From @jkeenan

On Sun, 08 Sep 2013 05​:25​:23 GMT, sprout wrote​:

On Sat Sep 07 02​:21​:21 2013, davem wrote​:

On Fri, Sep 06, 2013 at 07​:24​:44PM -0700, James E Keenan via RT wrote​:

On Wed Oct 25 08​:41​:02 2000, hv@​crypt.compulink.co.uk wrote​:

(After a report in clp.moderated from Peter Scott <peter@​psdt.com>.)

perl -Dr -we '(($y) = "x") =~ s/a/b/'

shows that a) perl is trying to perform the substitution on the
string
'1' which is not what the caller intended, and b) '1' is not marked
readonly in this context, so no error is reported. I think both of
these are bugs​: I think the former should be fixed by giving an
error
if the LHS of a binding operator is supplied as a list, and that the
latter should be fixed (if still relevant) by marking the count of
list elements as readonly.

I don't think either of these are bugs.

In the first instance, its a list assignment evaluated in scalar context,
which is well-defined as returning the number of elements assigned.
The result may be slightly unexpected to the uninitiated, but its no
different than say

$count = \(\($y\) = "x"\);

which sets count to 1.

In the second instance, (($y) = "x") in scalar context is an expression
that returns a well-defined numeric value. I see no rationale for it
to be read-only, any more than any other expression should return a
read-only value.

Hmm, but should aassign be allowed as a scalar lvalue?

We also allow​:

read STDIN, @​a=qw(foo bar), 10

Should we?

(I wrote earlier that I agreed. Now I’m not sure. Reopening....)

More than 3 years later there has been no support for this idead -- indeed, no further comment in this RT. So I recommend we re-close it.

Thank you very much.

--
James E Keenan (jkeenan@​cpan.org)

From @xsawyerx

On Mon, 02 Jan 2017 05​:26​:57 -0800, jkeenan wrote​:

On Sun, 08 Sep 2013 05​:25​:23 GMT, sprout wrote​:

On Sat Sep 07 02​:21​:21 2013, davem wrote​:

On Fri, Sep 06, 2013 at 07​:24​:44PM -0700, James E Keenan via RT
wrote​:

On Wed Oct 25 08​:41​:02 2000, hv@​crypt.compulink.co.uk wrote​:

(After a report in clp.moderated from Peter Scott
<peter@​psdt.com>.)

perl -Dr -we '(($y) = "x") =~ s/a/b/'

shows that a) perl is trying to perform the substitution on
the
string
'1' which is not what the caller intended, and b) '1' is not
marked
readonly in this context, so no error is reported. I think
both of
these are bugs​: I think the former should be fixed by giving
an
error
if the LHS of a binding operator is supplied as a list, and
that the
latter should be fixed (if still relevant) by marking the
count of
list elements as readonly.

I don't think either of these are bugs.

In the first instance, its a list assignment evaluated in scalar
context,
which is well-defined as returning the number of elements assigned.
The result may be slightly unexpected to the uninitiated, but its
no
different than say

$count = (($y) = "x");

which sets count to 1.

In the second instance, (($y) = "x") in scalar context is an
expression
that returns a well-defined numeric value. I see no rationale for
it
to be read-only, any more than any other expression should return a
read-only value.

Hmm, but should aassign be allowed as a scalar lvalue?

We also allow​:

read STDIN, @​a=qw(foo bar), 10

Should we?

(I wrote earlier that I agreed. Now I’m not sure. Reopening....)

More than 3 years later there has been no support for this idead --
indeed, no further comment in this RT. So I recommend we re-close it.

I recommend we seek affirmation to closing this from either Dave or Father C.

From @iabyn

On Sat, Sep 07, 2013 at 10​:25​:24PM -0700, Father Chrysostomos via RT wrote​:

On Sat Sep 07 02​:21​:21 2013, davem wrote​:

On Fri, Sep 06, 2013 at 07​:24​:44PM -0700, James E Keenan via RT wrote​:

On Wed Oct 25 08​:41​:02 2000, hv@​crypt.compulink.co.uk wrote​:

(After a report in clp.moderated from Peter Scott <peter@​psdt.com>.)

perl -Dr -we '(($y) = "x") =~ s/a/b/'

shows that a) perl is trying to perform the substitution on the
string
'1' which is not what the caller intended, and b) '1' is not marked
readonly in this context, so no error is reported. I think both of
these are bugs​: I think the former should be fixed by giving an
error
if the LHS of a binding operator is supplied as a list, and that the
latter should be fixed (if still relevant) by marking the count of
list elements as readonly.

I don't think either of these are bugs.

In the first instance, its a list assignment evaluated in scalar context,
which is well-defined as returning the number of elements assigned.
The result may be slightly unexpected to the uninitiated, but its no
different than say

$count = \(\($y\) = "x"\);

which sets count to 1.

In the second instance, (($y) = "x") in scalar context is an expression
that returns a well-defined numeric value. I see no rationale for it
to be read-only, any more than any other expression should return a
read-only value.

Hmm, but should aassign be allowed as a scalar lvalue?

We also allow​:

read STDIN, @​a=qw(foo bar), 10

Should we?

(I wrote earlier that I agreed. Now I’m not sure. Reopening....)

I'm now more inclined to think that it should be a compile-time error.

c.f.

  my $p = 10;
  my $q = 20;
  my $x = (($p + $q) =~ s/3/4/);

which gives

  Can't modify addition (+) in substitution (s///) at /home/davem/tmp/p line 7, near "s/3/4/)"

(while changing it to s/3/4/r is legal and sets $x to 40).

--
I don't want to achieve immortality through my work...
I want to achieve it through not dying.
  -- Woody Allen