Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Old package separator syntax #16270

Open
p5pRT opened this issue Nov 22, 2017 · 27 comments
Open

Old package separator syntax #16270

p5pRT opened this issue Nov 22, 2017 · 27 comments

Comments

@p5pRT
Copy link

@p5pRT p5pRT commented Nov 22, 2017

Migrated from rt.perl.org#132485 (status was 'open')

Searchable as RT132485$

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Nov 22, 2017

From @epa

For a long time the normal way to write the package separator in variable names has been :​: but the older ' form is still accepted.

(I believe that the newer form came in with Perl 5 but I am not sure; anyhow it certainly predates my first use of Perl twenty years ago.)

A gotcha with ' has long been mentioned in the Camel book​:

  "This is $owner's house"

That parses the same as $owner​::s and you get a warning at run time, so you can work out what is going on, but it is quite strange if you didn't know about the old ' package separator syntax. (I did know about it but I still fell into the trap of writing code like the

above.)

Might it be time to mark the old package separator as deprecated?

That would allow a compile time (rather than run time) diagnostic on the use of it. Eventually, once the old syntax is removed, "$owner's house" would work as expected.

The suggestion to deprecate things can trigger fierce discussion, so as a fallback position I would advocate a warning when the '

form is used inside a doublequote-interpolated string.


Flags​:

  category=core

  severity=low


Site configuration information for perl 5.22.2​:

Configured by Red Hat, Inc. at Fri Nov 4 14​:35​:02 UTC 2016.

Summary of my perl5 (revision 5 version 22 subversion 2) configuration​:

  Platform​:

  osname=linux, osvers=4.7.9-200.fc24.x86_64, archname=x86_64-linux-thread-multi

  uname='linux buildvm-12.phx2.fedoraproject.org 4.7.9-200.fc24.x86_64 #1 smp thu oct 20 14​:26​:16 utc 2016 x86_64 x86_64 x86_64 gnulinux '

  config_args='-des -Doptimize=none -Dccflags=-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -Dldflags=-Wl,-z,relro -Dccdlflags=-Wl,--enable-new-dtags -Wl,-z,relro -Dlddlflags=-shared -Wl,-z,relro -Dshrpdir=/usr/lib64 -DDEBUGGING=-g -Dversion=5.22.2 -Dmyhostname=localhost -Dperladmin=root@​localhost -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dprefix=/usr -Dvendorprefix=/usr -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl5 -Dsitearch=/usr/local/lib64/perl5 -Dprivlib=/usr/share/perl5 -Dvendorlib=/usr/share/perl5/vendor_perl -Darchlib=/usr/lib64/perl5 -Dvendorarch=/usr/lib64/perl5/vendor_perl -Darchname=x86_64-linux-thread-multi -Dlibpth=/usr/local/lib64 /lib64 /usr/lib64 -Duseshrplib -Dusethreads -Duseithreads -Dusedtrace=/usr/bin/dtrace -Duselargefiles -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl=n -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr -Dd_gethostent_r_proto -Ud_endhostent_r_proto -Ud_sethostent_r_proto -Ud_endprotoent_r_proto -Ud_setprotoent_r_proto -Ud_endservent_r_proto -Ud_setservent_r_proto -Dscriptdir=/usr/bin -Dusesitecustomize'

  hint=recommended, useposix=true, d_sigaction=define

  useithreads=define, usemultiplicity=define

  use64bitint=define, use64bitall=define, uselongdouble=undef

  usemymalloc=n, bincompat5005=undef

  Compiler​:

  cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -fwrapv -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',

  optimize=' -g',

  cppflags='-D_REENTRANT -D_GNU_SOURCE -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -fwrapv -fno-strict-aliasing -I/usr/local/include'

  ccversion='', gccversion='5.3.1 20160406 (Red Hat 5.3.1-6)', gccosandvers=''

  intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678, doublekind=3

  d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16, longdblkind=3

  ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8

  alignbytes=8, prototype=define

  Linker and Libraries​:

  ld='gcc', ldflags ='-Wl,-z,relro -fstack-protector-strong -L/usr/local/lib'

  libpth=/usr/local/lib64 /lib64 /usr/lib64 /usr/local/lib /usr/lib /lib/../lib64 /usr/lib/../lib64 /lib

  libs=-lpthread -lresolv -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc -lgdbm_compat

  perllibs=-lpthread -lresolv -lnsl -ldl -lm -lcrypt -lutil -lc

  libc=libc-2.22.so, so=so, useshrplib=true, libperl=libperl.so

  gnulibc_version='2.22'

  Dynamic Linking​:

  dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,--enable-new-dtags -Wl,-z,relro '

  cccdlflags='-fPIC', lddlflags='-shared -Wl,-z,relro -L/usr/local/lib -fstack-protector-strong'

Locally applied patches​:

  Fedora Patch1​: Removes date check, Fedora/RHEL specific

  Fedora Patch3​: support for libdir64

  Fedora Patch4​: use libresolv instead of libbind

  Fedora Patch5​: USE_MM_LD_RUN_PATH

  Fedora Patch6​: Skip hostname tests, due to builders not being network capable

  Fedora Patch7​: Dont run one io test due to random builder failures

  Fedora Patch15​: Define SONAME for libperl.so

  Fedora Patch16​: Install libperl.so to -Dshrpdir value

  Fedora Patch22​: Document Math​::BigInt​::CalcEmu requires Math​::BigInt (CPAN RT#85015)

  Fedora Patch26​: Make *DBM_File desctructors thread-safe (RT#61912)

  Fedora Patch27​: Make PadlistNAMES() lvalue again (CPAN RT#101063)

  Fedora Patch28​: Make magic vtable writable as a work-around for Coro (CPAN RT#101063)

  Fedora Patch29​: Fix duplicating PerlIO​::encoding when spawning threads (RT#31923)

  Fedora Patch30​: Do not let XSLoader load relative paths (CVE-2016-6185)

  Fedora Patch31​: Avoid loading optional modules from default . (CVE-2016-1238)

  Fedora Patch32​: Fix a crash in lexical scope warnings (RT#128597)

  Fedora Patch33​: Do not mangle errno from failed socket calls (RT#128316)

  Fedora Patch34​: Fix crash in "evalbytes S" (RT#129196)

  Fedora Patch35​: Fix crash in "evalbytes S" (RT#129196)

  Fedora Patch36​: Fix crash in "evalbytes S" (RT#129196)

  Fedora Patch37​: Fix crash in splice (RT#129164, RT#129166, RT#129167)

  Fedora Patch38​: Fix string overrun in Perl_gv_fetchmethod_pvn_flags (RT#129267)

  Fedora Patch39​: Fix string overrun in Perl_gv_fetchmethod_pvn_flags (RT#129267)

  Fedora Patch40​: Fix string overrun in Perl_gv_fetchmethod_pvn_flags (RT#129267)

  Fedora Patch41​: Fix string overrun in Perl_gv_fetchmethod_pvn_flags (RT#129267)

  Fedora Patch42​: Fix string overrun in Perl_gv_fetchmethod_pvn_flags (RT#129267)

  Fedora Patch43​: Fix crash when matching UTF-8 string with non-UTF-8 substrings (RT#129350)

  Fedora Patch44​: Fix parsing perl options in shell bang line (RT#129336)

  Fedora Patch45​: Fix firstchar bitmap under UTF-8 with prefix optimization (RT#129950)

  Fedora Patch46​: Avoid infinite loop in h2xs tool if enum and type have the same name (RT130001)

  Fedora Patch47​: Fix stack handling when calling chdir without an argument (RT#129130)

  Fedora Patch200​: Link XS modules to libperl.so with EU​::CBuilder on Linux

  Fedora Patch201​: Link XS modules to libperl.so with EU​::MM on Linux


@​INC for perl 5.22.2​:

  /home/eda/lib64/perl5/

  /usr/local/lib64/perl5

  /usr/local/share/perl5

  /usr/lib64/perl5/vendor_perl

  /usr/share/perl5/vendor_perl

  /usr/lib64/perl5

  /usr/share/perl5


Environment for perl 5.22.2​:

  HOME=/home/eda

  LANG=en_GB.UTF-8

  LANGUAGE (unset)

  LC_COLLATE=C

  LC_CTYPE=en_GB.UTF-8

  LC_MESSAGES=en_GB.UTF-8

  LC_MONETARY=en_GB.UTF-8

  LC_NUMERIC=en_GB.UTF-8

  LC_TIME=en_GB.UTF-8

  LD_LIBRARY_PATH (unset)

  LOGDIR (unset)

  PATH=/home/eda/bin​:/home/eda/bin​:/home/eda/bin​:/usr/local/bin​:/usr/bin​:/usr/local/sbin​:/usr/sbin​:/sbin​:/usr/sbin​:/home/eda/.local/bin​:/home/eda/bin​:/sbin​:/usr/sbin​:/sbin​:/usr/sbin

  PERL5LIB=/home/eda/lib64/perl5/

  PERL_BADLANG (unset)

  SHELL=/bin/bash

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Nov 22, 2017

From @epa

Repeating message text since not shown in web interface.

For a long time the normal way to write the package separator in variable names has been :​: but the older ' form is still accepted.
(I believe that the newer form came in with Perl 5 but I am not sure; anyhow it certainly predates my first use of Perl twenty years ago.)

A gotcha with ' has long been mentioned in the Camel book​:

  "This is $owner's house"

That parses the same as $owner​::s and you get a warning at run time, so you can work out what is going on, but it is quite strange if you didn't know about the old ' package separator syntax. (I did know about it but I still fell into the trap of writing code like the
above.)

Might it be time to mark the old package separator as deprecated?
That would allow a compile time (rather than run time) diagnostic on the use of it. Eventually, once the old syntax is removed, "$owner's house" would work as expected.

The suggestion to deprecate things can trigger fierce discussion, so as a fallback position I would advocate a warning when the '
form is used inside a doublequote-interpolated string.


Flags​:
  category=core
  severity=low


Site configuration information for perl 5.22.2​:

Configured by Red Hat, Inc. at Fri Nov 4 14​:35​:02 UTC 2016.

Summary of my perl5 (revision 5 version 22 subversion 2) configuration​:
 
  Platform​:
  osname=linux, osvers=4.7.9-200.fc24.x86_64, archname=x86_64-linux-thread-multi
  uname='linux buildvm-12.phx2.fedoraproject.org 4.7.9-200.fc24.x86_64 #1 smp thu oct 20 14​:26​:16 utc 2016 x86_64 x86_64 x86_64 gnulinux '
  config_args='-des -Doptimize=none -Dccflags=-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -Dldflags=-Wl,-z,relro -Dccdlflags=-Wl,--enable-new-dtags -Wl,-z,relro -Dlddlflags=-shared -Wl,-z,relro -Dshrpdir=/usr/lib64 -DDEBUGGING=-g -Dversion=5.22.2 -Dmyhostname=localhost -Dperladmin=root@​localhost -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dprefix=/usr -Dvendorprefix=/usr -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl5 -Dsitearch=/usr/local/lib64/perl5 -Dprivlib=/usr/share/perl5 -Dvendorlib=/usr/share/perl5/vendor_perl -Darchlib=/usr/lib64/perl5 -Dvendorarch=/usr/lib64/perl5/vendor_perl -Darchname=x86_64-linux-thread-multi -Dlibpth=/usr/local/lib64 /lib64 /usr/lib64 -Duseshrplib -Dusethreads -Duseithreads -Dusedtrace=/usr/bin/dtrace -Duselargefiles -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl=n -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr -Dd_gethostent_r_proto -Ud_endhostent_r_proto -Ud_sethostent_r_proto -Ud_endprotoent_r_proto -Ud_setprotoent_r_proto -Ud_endservent_r_proto -Ud_setservent_r_proto -Dscriptdir=/usr/bin -Dusesitecustomize'
  hint=recommended, useposix=true, d_sigaction=define
  useithreads=define, usemultiplicity=define
  use64bitint=define, use64bitall=define, uselongdouble=undef
  usemymalloc=n, bincompat5005=undef
  Compiler​:
  cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -fwrapv -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
  optimize=' -g',
  cppflags='-D_REENTRANT -D_GNU_SOURCE -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -fwrapv -fno-strict-aliasing -I/usr/local/include'
  ccversion='', gccversion='5.3.1 20160406 (Red Hat 5.3.1-6)', gccosandvers=''
  intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678, doublekind=3
  d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16, longdblkind=3
  ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
  alignbytes=8, prototype=define
  Linker and Libraries​:
  ld='gcc', ldflags ='-Wl,-z,relro -fstack-protector-strong -L/usr/local/lib'
  libpth=/usr/local/lib64 /lib64 /usr/lib64 /usr/local/lib /usr/lib /lib/../lib64 /usr/lib/../lib64 /lib
  libs=-lpthread -lresolv -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc -lgdbm_compat
  perllibs=-lpthread -lresolv -lnsl -ldl -lm -lcrypt -lutil -lc
  libc=libc-2.22.so, so=so, useshrplib=true, libperl=libperl.so
  gnulibc_version='2.22'
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,--enable-new-dtags -Wl,-z,relro '
  cccdlflags='-fPIC', lddlflags='-shared -Wl,-z,relro -L/usr/local/lib -fstack-protector-strong'

Locally applied patches​:
  Fedora Patch1​: Removes date check, Fedora/RHEL specific
  Fedora Patch3​: support for libdir64
  Fedora Patch4​: use libresolv instead of libbind
  Fedora Patch5​: USE_MM_LD_RUN_PATH
  Fedora Patch6​: Skip hostname tests, due to builders not being network capable
  Fedora Patch7​: Dont run one io test due to random builder failures
  Fedora Patch15​: Define SONAME for libperl.so
  Fedora Patch16​: Install libperl.so to -Dshrpdir value
  Fedora Patch22​: Document Math​::BigInt​::CalcEmu requires Math​::BigInt (CPAN RT#85015)
  Fedora Patch26​: Make *DBM_File desctructors thread-safe (RT#61912)
  Fedora Patch27​: Make PadlistNAMES() lvalue again (CPAN RT#101063)
  Fedora Patch28​: Make magic vtable writable as a work-around for Coro (CPAN RT#101063)
  Fedora Patch29​: Fix duplicating PerlIO​::encoding when spawning threads (RT#31923)
  Fedora Patch30​: Do not let XSLoader load relative paths (CVE-2016-6185)
  Fedora Patch31​: Avoid loading optional modules from default . (CVE-2016-1238)
  Fedora Patch32​: Fix a crash in lexical scope warnings (RT#128597)
  Fedora Patch33​: Do not mangle errno from failed socket calls (RT#128316)
  Fedora Patch34​: Fix crash in "evalbytes S" (RT#129196)
  Fedora Patch35​: Fix crash in "evalbytes S" (RT#129196)
  Fedora Patch36​: Fix crash in "evalbytes S" (RT#129196)
  Fedora Patch37​: Fix crash in splice (RT#129164, RT#129166, RT#129167)
  Fedora Patch38​: Fix string overrun in Perl_gv_fetchmethod_pvn_flags (RT#129267)
  Fedora Patch39​: Fix string overrun in Perl_gv_fetchmethod_pvn_flags (RT#129267)
  Fedora Patch40​: Fix string overrun in Perl_gv_fetchmethod_pvn_flags (RT#129267)
  Fedora Patch41​: Fix string overrun in Perl_gv_fetchmethod_pvn_flags (RT#129267)
  Fedora Patch42​: Fix string overrun in Perl_gv_fetchmethod_pvn_flags (RT#129267)
  Fedora Patch43​: Fix crash when matching UTF-8 string with non-UTF-8 substrings (RT#129350)
  Fedora Patch44​: Fix parsing perl options in shell bang line (RT#129336)
  Fedora Patch45​: Fix firstchar bitmap under UTF-8 with prefix optimization (RT#129950)
  Fedora Patch46​: Avoid infinite loop in h2xs tool if enum and type have the same name (RT130001)
  Fedora Patch47​: Fix stack handling when calling chdir without an argument (RT#129130)
  Fedora Patch200​: Link XS modules to libperl.so with EU​::CBuilder on Linux
  Fedora Patch201​: Link XS modules to libperl.so with EU​::MM on Linux


@​INC for perl 5.22.2​:
  /home/eda/lib64/perl5/
  /usr/local/lib64/perl5
  /usr/local/share/perl5
  /usr/lib64/perl5/vendor_perl
  /usr/share/perl5/vendor_perl
  /usr/lib64/perl5
  /usr/share/perl5


Environment for perl 5.22.2​:
  HOME=/home/eda
  LANG=en_GB.UTF-8
  LANGUAGE (unset)
  LC_COLLATE=C
  LC_CTYPE=en_GB.UTF-8
  LC_MESSAGES=en_GB.UTF-8
  LC_MONETARY=en_GB.UTF-8
  LC_NUMERIC=en_GB.UTF-8
  LC_TIME=en_GB.UTF-8
  LD_LIBRARY_PATH (unset)
  LOGDIR (unset)
  PATH=/home/eda/bin​:/home/eda/bin​:/home/eda/bin​:/usr/local/bin​:/usr/bin​:/usr/local/sbin​:/usr/sbin​:/sbin​:/usr/sbin​:/home/eda/.local/bin​:/home/eda/bin​:/sbin​:/usr/sbin​:/sbin​:/usr/sbin
  PERL5LIB=/home/eda/lib64/perl5/
  PERL_BADLANG (unset)
  SHELL=/bin/bash

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Nov 22, 2017

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Nov 22, 2017

From gdg@zplane.com

Ed Avis <perlbug-followup@​perl.org> [2017-11-22 08​:04​:05 -0800]​:

For a long time the normal way to write the package separator in
variable names has been :​: but the older ' form is still accepted.

(I believe that the newer form came in with Perl 5 but I am not sure;
anyhow it certainly predates my first use of Perl twenty years ago.)

A gotcha with ' has long been mentioned in the Camel book​:

"This is $owner's house"

That parses the same as $owner​::s and you get a warning at run time, so
you can work out what is going on, but it is quite strange if you didn't
know about the old ' package separator syntax. (I did know about it but
I still fell into the trap of writing code like the above.)

Might it be time to mark the old package separator as deprecated?

The suggestion to deprecate things can trigger fierce discussion, so as
a fallback position I would advocate a warning when the ' form is used
inside a doublequote-interpolated string.

+1 from the Moron Gallery for deprecation, or improving the emitted message
("Name 'owner​::s' used only once​: possible typo at...").

This is one of our favorite forms of periodic self-mystification​: We do it
juuust infrequently enough to exceed our recollection horizon as to the
cause, but the message text isn't quite sufficient to (re)make the mental
connection to the old syntax.

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Nov 22, 2017

From @exodist

I agree that it would be good to get rid of ' as a package separator, that
said there are a few things that this will break, mostly ACME or other
silly modules, but some serious.

Off the top of my head​:

isn't (isn​::t) as defined by Test​::More since the dawn of time (I did not
add this, it is legacy from before my time). At the very least Test​::More
would need a patch to define it without the ' on perl's that have no '
separator. I do not think isn't(...) ever saw widepsread usage, but it may
have, so there could also be a ton of tests to clean up.

This also bring up the point that a lot of modules that take module names
as arguments support ', that is not so much a problem, what is a problem is
any tests they have to verify the support, those may break depending on how
they are implemented.

Here is a silly one that will still work, but the intended usage form
breaks (I wrote this one)​:
https://metacpan.org/pod/Fuckin::Lazy#Fuckin'Lazy($var)

That said, I think the benefit of ditching the ' package separator
outweighs the comedic benefit, and the trouble to fix things that currently
use/recommend it.

Final note​: I wonder if it something that can be turned off via a pragma?
use strict 'separator'; perhaps (and maybe make it a default, where using
strict makes it deprecated?)

-Chad

On Wed, Nov 22, 2017 at 8​:04 AM, Ed Avis <perlbug-followup@​perl.org> wrote​:

# New Ticket Created by "Ed Avis"
# Please include the string​: [perl #132485]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=132485 >

For a long time the normal way to write the package separator in variable
names has been :​: but the older ' form is still accepted.

(I believe that the newer form came in with Perl 5 but I am not sure;
anyhow it certainly predates my first use of Perl twenty years ago.)

A gotcha with ' has long been mentioned in the Camel book​:

"This is $owner's house"

That parses the same as $owner​::s and you get a warning at run time, so
you can work out what is going on, but it is quite strange if you didn't
know about the old ' package separator syntax. (I did know about it but I
still fell into the trap of writing code like the

above.)

Might it be time to mark the old package separator as deprecated?

That would allow a compile time (rather than run time) diagnostic on the
use of it. Eventually, once the old syntax is removed, "$owner's house"
would work as expected.

The suggestion to deprecate things can trigger fierce discussion, so as a
fallback position I would advocate a warning when the '

form is used inside a doublequote-interpolated string.

---

Flags​:

category=core

severity=low

---

Site configuration information for perl 5.22.2​:

Configured by Red Hat, Inc. at Fri Nov 4 14​:35​:02 UTC 2016.

Summary of my perl5 (revision 5 version 22 subversion 2) configuration​:

Platform​:

osname=linux\, osvers=4\.7\.9\-200\.fc24\.x86\_64\,

archname=x86_64-linux-thread-multi

uname='linux buildvm\-12\.phx2\.fedoraproject\.org 4\.7\.9\-200\.fc24\.x86\_64

#1 smp thu oct 20 14​:26​:16 utc 2016 x86_64 x86_64 x86_64 gnulinux '

config\_args='\-des \-Doptimize=none \-Dccflags=\-O2 \-g \-pipe \-Wall

-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches
-m64 -mtune=generic -Dldflags=-Wl,-z,relro -Dccdlflags=-Wl,--enable-new-dtags
-Wl,-z,relro -Dlddlflags=-shared -Wl,-z,relro -Dshrpdir=/usr/lib64
-DDEBUGGING=-g -Dversion=5.22.2 -Dmyhostname=localhost
-Dperladmin=root@​localhost -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dprefix=/usr
-Dvendorprefix=/usr -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl5
-Dsitearch=/usr/local/lib64/perl5 -Dprivlib=/usr/share/perl5
-Dvendorlib=/usr/share/perl5/vendor_perl -Darchlib=/usr/lib64/perl5
-Dvendorarch=/usr/lib64/perl5/vendor_perl -Darchname=x86_64-linux-thread-multi
-Dlibpth=/usr/local/lib64 /lib64 /usr/lib64 -Duseshrplib -Dusethreads
-Duseithreads -Dusedtrace=/usr/bin/dtrace -Duselargefiles -Dd_semctl_semun
-Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio
-Dinstallu
srbinperl=n -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr
-Dd_gethostent_r_proto -Ud_endhostent_r_proto -Ud_sethostent_r_proto
-Ud_endprotoent_r_proto -Ud_setprotoent_r_proto -Ud_endservent_r_proto
-Ud_setservent_r_proto -Dscriptdir=/usr/bin -Dusesitecustomize'

hint=recommended\, useposix=true\, d\_sigaction=define

useithreads=define\, usemultiplicity=define

use64bitint=define\, use64bitall=define\, uselongdouble=undef

usemymalloc=n\, bincompat5005=undef

Compiler​:

cc='gcc'\, ccflags ='\-D\_REENTRANT \-D\_GNU\_SOURCE \-O2 \-g \-pipe \-Wall

-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches
-m64 -mtune=generic -fwrapv -fno-strict-aliasing -I/usr/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',

optimize='  \-g'\,

cppflags='\-D\_REENTRANT \-D\_GNU\_SOURCE \-O2 \-g \-pipe \-Wall

-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches
-m64 -mtune=generic -fwrapv -fno-strict-aliasing -I/usr/local/include'

ccversion=''\, gccversion='5\.3\.1 20160406 \(Red Hat 5\.3\.1\-6\)'\,

gccosandvers=''

intsize=4\, longsize=8\, ptrsize=8\, doublesize=8\, byteorder=12345678\,

doublekind=3

d\_longlong=define\, longlongsize=8\, d\_longdbl=define\, longdblsize=16\,

longdblkind=3

ivtype='long'\, ivsize=8\, nvtype='double'\, nvsize=8\, Off\_t='off\_t'\,

lseeksize=8

alignbytes=8\, prototype=define

Linker and Libraries​:

ld='gcc'\, ldflags ='\-Wl\,\-z\,relro  \-fstack\-protector\-strong

-L/usr/local/lib'

libpth=/usr/local/lib64 /lib64 /usr/lib64 /usr/local/lib /usr/lib

/lib/../lib64 /usr/lib/../lib64 /lib

libs=\-lpthread \-lresolv \-lnsl \-lgdbm \-ldb \-ldl \-lm \-lcrypt \-lutil \-lc

-lgdbm_compat

perllibs=\-lpthread \-lresolv \-lnsl \-ldl \-lm \-lcrypt \-lutil \-lc

libc=libc\-2\.22\.so\, so=so\, useshrplib=true\, libperl=libperl\.so

gnulibc\_version='2\.22'

Dynamic Linking​:

dlsrc=dl\_dlopen\.xs\, dlext=so\, d\_dlsymun=undef\,

ccdlflags='-Wl,--enable-new-dtags -Wl,-z,relro '

cccdlflags='\-fPIC'\, lddlflags='\-shared \-Wl\,\-z\,relro  \-L/usr/local/lib

-fstack-protector-strong'

Locally applied patches​:

Fedora Patch1&#8203;: Removes date check\, Fedora/RHEL specific

Fedora Patch3&#8203;: support for libdir64

Fedora Patch4&#8203;: use libresolv instead of libbind

Fedora Patch5&#8203;: USE\_MM\_LD\_RUN\_PATH

Fedora Patch6&#8203;: Skip hostname tests\, due to builders not being network

capable

Fedora Patch7&#8203;: Dont run one io test due to random builder failures

Fedora Patch15&#8203;: Define SONAME for libperl\.so

Fedora Patch16&#8203;: Install libperl\.so to \-Dshrpdir value

Fedora Patch22&#8203;: Document Math&#8203;::BigInt&#8203;::CalcEmu requires Math&#8203;::BigInt

(CPAN RT#85015)

Fedora Patch26&#8203;: Make \*DBM\_File desctructors thread\-safe \(RT\#61912\)

Fedora Patch27&#8203;: Make PadlistNAMES\(\) lvalue again \(CPAN RT\#101063\)

Fedora Patch28&#8203;: Make magic vtable writable as a work\-around for Coro

(CPAN RT#101063)

Fedora Patch29&#8203;: Fix duplicating PerlIO&#8203;::encoding when spawning threads

(RT#31923)

Fedora Patch30&#8203;: Do not let XSLoader load relative paths \(CVE\-2016\-6185\)

Fedora Patch31&#8203;: Avoid loading optional modules from default \.

(CVE-2016-1238)

Fedora Patch32&#8203;: Fix a crash in lexical scope warnings \(RT\#128597\)

Fedora Patch33&#8203;: Do not mangle errno from failed socket calls

(RT#128316)

Fedora Patch34&#8203;: Fix crash in "evalbytes S" \(RT\#129196\)

Fedora Patch35&#8203;: Fix crash in "evalbytes S" \(RT\#129196\)

Fedora Patch36​: Fix crash in "evalbytes S" (RT#129196)

Fedora Patch37&#8203;: Fix crash in splice \(RT\#129164\, RT\#129166\, RT\#129167\)

Fedora Patch38&#8203;: Fix string overrun in Perl\_gv\_fetchmethod\_pvn\_flags

(RT#129267)

Fedora Patch39&#8203;: Fix string overrun in Perl\_gv\_fetchmethod\_pvn\_flags

(RT#129267)

Fedora Patch40&#8203;: Fix string overrun in Perl\_gv\_fetchmethod\_pvn\_flags

(RT#129267)

Fedora Patch41&#8203;: Fix string overrun in Perl\_gv\_fetchmethod\_pvn\_flags

(RT#129267)

Fedora Patch42&#8203;: Fix string overrun in Perl\_gv\_fetchmethod\_pvn\_flags

(RT#129267)

Fedora Patch43&#8203;: Fix crash when matching UTF\-8 string with non\-UTF\-8

substrings (RT#129350)

Fedora Patch44&#8203;: Fix parsing perl options in shell bang line \(RT\#129336\)

Fedora Patch45&#8203;: Fix firstchar bitmap under UTF\-8 with prefix

optimization (RT#129950)

Fedora Patch46&#8203;: Avoid infinite loop in h2xs tool if enum and type have

the same name (RT130001)

Fedora Patch47&#8203;: Fix stack handling when calling chdir without an

argument (RT#129130)

Fedora Patch200&#8203;: Link XS modules to libperl\.so with EU&#8203;::CBuilder on

Linux

Fedora Patch201&#8203;: Link XS modules to libperl\.so with EU&#8203;::MM on Linux

---

@​INC for perl 5.22.2​:

/home/eda/lib64/perl5/

/usr/local/lib64/perl5

/usr/local/share/perl5

/usr/lib64/perl5/vendor\_perl

/usr/share/perl5/vendor\_perl

/usr/lib64/perl5

/usr/share/perl5

---

Environment for perl 5.22.2​:

HOME=/home/eda

LANG=en\_GB\.UTF\-8

LANGUAGE \(unset\)

LC\_COLLATE=C

LC\_CTYPE=en\_GB\.UTF\-8

LC\_MESSAGES=en\_GB\.UTF\-8

LC\_MONETARY=en\_GB\.UTF\-8

LC\_NUMERIC=en\_GB\.UTF\-8

LC\_TIME=en\_GB\.UTF\-8

LD\_LIBRARY\_PATH \(unset\)

LOGDIR \(unset\)

PATH=/home/eda/bin&#8203;:/home/eda/bin&#8203;:/home/eda/bin&#8203;:/usr/local/

bin​:/usr/bin​:/usr/local/sbin​:/usr/sbin​:/sbin​:/usr/sbin​:/
home/eda/.local/bin​:/home/eda/bin​:/sbin​:/usr/sbin​:/sbin​:/usr/sbin

PERL5LIB=/home/eda/lib64/perl5/

PERL\_BADLANG \(unset\)

SHELL=/bin/bash
@p5pRT
Copy link
Author

@p5pRT p5pRT commented Nov 22, 2017

From zefram@fysh.org

Ed Avis wrote​:

Might it be time to mark the old package separator as deprecated?

It's an the fuzzy boundary of what we consider deprecatable. It's rarely
used, and sane affected code can be easily updated to continue working.
We wouldn't be too bothered about the cute hacks like "isn't()" and
"don't {}". But it doesn't really stand in the way of actual improvement
to the Perl language or perl interpreter. The motivation of accidental
usage is mild; those bugs show up quickly.

-zefram

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Nov 22, 2017

From @cpansprout

On Wed, 22 Nov 2017 11​:43​:11 -0800, zefram@​fysh.org wrote​:

Ed Avis wrote​:

Might it be time to mark the old package separator as deprecated?

It's an the fuzzy boundary of what we consider deprecatable. It's rarely
used, and sane affected code can be easily updated to continue working.

I have continued to use it, because it’s shorter and quicker to type than :​:. I would be all in favour of the proposed warning, though, if only to allay the threat of deprecation.

[I]t doesn't really stand in the way of actual improvement
to the Perl language or perl interpreter. The motivation of accidental
usage is mild; those bugs show up quickly.

I agree.

--

Father Chrysostomos

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Nov 22, 2017

From @cpansprout

On Wed, 22 Nov 2017 10​:11​:50 -0800, exodist7@​gmail.com wrote​:

Final note​: I wonder if it something that can be turned off via a
pragma?
use strict 'separator'; perhaps (and maybe make it a default, where
using
strict makes it deprecated?)

I looked into that several years ago. Making it dependent on a pragma would add more conditions to fairly hot code (gv_fetchsv). It would probably slow things down (and cause bugs at the same time) without much benefit.

--

Father Chrysostomos

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Nov 22, 2017

From @exodist

On Wed, Nov 22, 2017 at 1​:03 PM, Father Chrysostomos via RT <
perlbug-followup@​perl.org> wrote​:

On Wed, 22 Nov 2017 10​:11​:50 -0800, exodist7@​gmail.com wrote​:

Final note​: I wonder if it something that can be turned off via a
pragma?
use strict 'separator'; perhaps (and maybe make it a default, where
using
strict makes it deprecated?)

I looked into that several years ago. Making it dependent on a pragma
would add more conditions to fairly hot code (gv_fetchsv). It would
probably slow things down (and cause bugs at the same time) without much
benefit.

--

Father Chrysostomos

---
via perlbug​: queue​: perl5 status​: open
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=132485

Thanks, sounds like it is not worth it then.

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Nov 22, 2017

From @epa

But it doesn't really stand in the way of actual improvement
to the Perl language or perl interpreter.

Viewed in abstract terms of language design, the ' package separator is rather weird. The ' character, almost everywhere in Unix and in Perl, is part of a matched delimiter. For it to sometimes appear solo is strange. Moreover, the need to parse it as a package separator sometimes affects its use as a string delimiter.

  sub foo { say $_[0] }
  foo"hi"; # works
  foo'hi'; # doesn't work

  foox"hi"; # String found where operator expected
  foo'"hi"; # Bad name after foo' (huh?)

It's not that hot as a synonym for :​: either​:

  sub foo' {} # Illegal declaration of subroutine main​::foo
  sub foo​:: {} # OK

  sub 'foo { say $_[0] }
  'foo 5; # Can't find string terminator "'"
  :​:foo 5; # OK

At the very least, this argues for forbidding the ' syntax at the start and end of identifiers. (I would also say that foo'hi' not working is a bug, when foo"hi" is fine.)

But the more important point is, this syntactic weirdness and possible ambiguity is another one to combine with all the other idiosyncrasies to result in crazy-sounding syntax errors or bizarre parses of a fairly simple typo. We've all had these WTF moments when writing Perl code; a simple change causes the parser to spew out error messages over several seemingly unrelated lines of code, with a bit of headscratching required (especially for the novice) to work out that it was all down to a bit of misplaced punctuation a couple of lines earlier. A lot of this is inevitable. A lot of the ambiguities in the grammar are the price we pay for richness, expressivity and concision. But this particular one doesn't enrich the language or (except for golfing) let you write shorter code. To regularize ' so that it follows broadly the same rules as " would be a small but noticeable improvement.

 

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Nov 26, 2017

From @cpansprout

On Wed, 22 Nov 2017 13​:03​:28 -0800, sprout wrote​:

On Wed, 22 Nov 2017 10​:11​:50 -0800, exodist7@​gmail.com wrote​:

Final note​: I wonder if it something that can be turned off via a
pragma?
use strict 'separator'; perhaps (and maybe make it a default, where
using
strict makes it deprecated?)

I looked into that several years ago. Making it dependent on a pragma
would add more conditions to fairly hot code (gv_fetchsv). It would
probably slow things down (and cause bugs at the same time) without
much benefit.

I have added this warning in commit 2cb35ee​:

$ ./perl -cwe '$name = <>; print "I visited $name'\''s house.\n"'
Old package separator used in string at -e line 1.
  (Did you mean "$name\'s"?) at -e line 1.
Name "name​::s" used only once​: possible typo at -e line 1.
Name "main​::name" used only once​: possible typo at -e line 1.
-e syntax OK

--

Father Chrysostomos

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Nov 26, 2017

From @exodist

What type of warning category is it? I have at least 1 test file where I
need to add a `no warnings '...'` for this.

On Sun, Nov 26, 2017 at 1​:42 PM, Father Chrysostomos via RT <
perlbug-followup@​perl.org> wrote​:

On Wed, 22 Nov 2017 13​:03​:28 -0800, sprout wrote​:

On Wed, 22 Nov 2017 10​:11​:50 -0800, exodist7@​gmail.com wrote​:

Final note​: I wonder if it something that can be turned off via a
pragma?
use strict 'separator'; perhaps (and maybe make it a default, where
using
strict makes it deprecated?)

I looked into that several years ago. Making it dependent on a pragma
would add more conditions to fairly hot code (gv_fetchsv). It would
probably slow things down (and cause bugs at the same time) without
much benefit.

I have added this warning in commit 2cb35ee​:

$ ./perl -cwe '$name = <>; print "I visited $name'\''s house.\n"'
Old package separator used in string at -e line 1.
(Did you mean "$name\'s"?) at -e line 1.
Name "name​::s" used only once​: possible typo at -e line 1.
Name "main​::name" used only once​: possible typo at -e line 1.
-e syntax OK

--

Father Chrysostomos

---
via perlbug​: queue​: perl5 status​: open
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=132485

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Nov 27, 2017

From @cpansprout

On Sun, 26 Nov 2017 15​:10​:45 -0800, exodist7@​gmail.com wrote​:

What type of warning category is it? I have at least 1 test file where I
need to add a `no warnings '...'` for this.

syntax

--

Father Chrysostomos

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Nov 27, 2017

From @epa

Thanks for adding this warning, Father C. That will explain a longstanding gotcha, although it doesn't remove it.

If the perl5-porters think it is worthwhile to move towards removing the old package separator syntax, I suggest that a first step would be to issue a deprecation warning when used in variable names, but continue to allow it for barewords.

  $foo'bar; # deprecated
  "hello $foo'bar"; # deprecated
  foo'bar(); # OK for now

I also suggest that at some point in the future when the ' is deprecated altogether, even in subroutine names, modules providing cute names like C<isn't> could do so with a simple source filter.

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Nov 27, 2017

From @kentfredric

On 28 November 2017 at 02​:55, Ed Avis via RT <perlbug-followup@​perl.org> wrote​:

modules providing cute names like C<isn't> could do so with a simple source filter.

Please no. That is far worse than leaving this feature in place.

--
Kent

KENTNL - https://metacpan.org/author/KENTNL

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Nov 27, 2017

From @Leont

On Mon, Nov 27, 2017 at 2​:55 PM, Ed Avis via RT <perlbug-followup@​perl.org>
wrote​:

Thanks for adding this warning, Father C. That will explain a
longstanding gotcha, although it doesn't remove it.

If the perl5-porters think it is worthwhile to move towards removing the
old package separator syntax, I suggest that a first step would be to issue
a deprecation warning when used in variable names, but continue to allow it
for barewords.

$foo'bar;         \# deprecated
"hello $foo'bar"; \# deprecated
foo'bar\(\);        \# OK for now

I also suggest that at some point in the future when the ' is deprecated
altogether, even in subroutine names, modules providing cute names like
C<isn't> could do so with a simple source filter.

For what benefit?

I see a benefit in removing them in quoted strings, because of the odds
it's used by mistake. I don't see any such problem in any other form of
single-quote as package separator. This sounds like breaking things for the
sake of breaking them.

Leon

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Nov 27, 2017

From @epa

As I say, it's "if". If people think that the older package separator syntax should be deprecated and eventually removed. That is something I would support, and I gave some arguments for it earlier. but there are certainly arguments for keeping it around.

*If* the perl5-porters do want to put the old syntax on the deprecation path, I suggest that the first step would be in variable names like C<$a'b>. The use in subroutine names could be left as a later step, partly because of existing code with isn't and perhaps other apostrophized names (Acme​::Don't).

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Nov 27, 2017

From @demerphq

On 27 November 2017 at 16​:22, Leon Timmermans <fawaka@​gmail.com> wrote​:

On Mon, Nov 27, 2017 at 2​:55 PM, Ed Avis via RT <perlbug-followup@​perl.org>
wrote​:

Thanks for adding this warning, Father C. That will explain a
longstanding gotcha, although it doesn't remove it.

If the perl5-porters think it is worthwhile to move towards removing the
old package separator syntax, I suggest that a first step would be to issue
a deprecation warning when used in variable names, but continue to allow it
for barewords.

$foo'bar;         \# deprecated
"hello $foo'bar"; \# deprecated
foo'bar\(\);        \# OK for now

I also suggest that at some point in the future when the ' is deprecated
altogether, even in subroutine names, modules providing cute names like
C<isn't> could do so with a simple source filter.

For what benefit?

I see a benefit in removing them in quoted strings, because of the odds it's
used by mistake. I don't see any such problem in any other form of
single-quote as package separator. This sounds like breaking things for the
sake of breaking them.

If it's worth removing them from quoted strings then it's worth
removing them altogether.

Yves

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Nov 27, 2017

From @andk

On Mon, 27 Nov 2017 17​:42​:37 +0100, demerphq <demerphq@​gmail.com> said​:

I see a benefit in removing them in quoted strings, because of the odds it's
used by mistake. I don't see any such problem in any other form of
single-quote as package separator. This sounds like breaking things for the
sake of breaking them.

  > If it's worth removing them from quoted strings then it's worth
  > removing them altogether.

And your argument is?

--
andreas

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Nov 27, 2017

From @demerphq

On 27 Nov 2017 20​:25, "Andreas Koenig" <
andreas.koenig.7os6VVqR@​franz.ak.mind.de> wrote​:

On Mon, 27 Nov 2017 17​:42​:37 +0100, demerphq <demerphq@​gmail.com>
said​:

I see a benefit in removing them in quoted strings, because of the odds
it's
used by mistake. I don't see any such problem in any other form of
single-quote as package separator. This sounds like breaking things for
the
sake of breaking them.

  > If it's worth removing them from quoted strings then it's worth
  > removing them altogether.

And your argument is?

Consistency. Either apostrophe is a valid replacement for colon-colon or
it's not. We don't need more special cases in perl, we have enough already.

Yves

Yves

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Nov 27, 2017

From @Leont

On Tue, Nov 28, 2017 at 12​:02 AM, demerphq <demerphq@​gmail.com> wrote​:

Consistency. Either apostrophe is a valid replacement for colon-colon or
it's not. We don't need more special cases in perl, we have enough already.

Consistency is useful when one needs to explain people how something works,
but as far as I'm concerned the only consistency we need is telling people
to please avoid it entirely.

Leon

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Nov 28, 2017

From @demerphq

On 28 Nov 2017 00​:46, "Leon Timmermans" <fawaka@​gmail.com> wrote​:

On Tue, Nov 28, 2017 at 12​:02 AM, demerphq <demerphq@​gmail.com> wrote​:

Consistency. Either apostrophe is a valid replacement for colon-colon or
it's not. We don't need more special cases in perl, we have enough already.

Consistency is useful when one needs to explain people how something works,
but as far as I'm concerned the only consistency we need is telling people
to please avoid it entirely.

And if that's our policy we should just deprecate and remove it.

Yves

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Nov 28, 2017

From @xsawyerx

I think this captures my thoughts on this at the moment.

Deprecating is a fragile process with which we should be judicious. We
should consider syntax or features (or misfeatures) that break other
features, stand in our way of further advancements and fixes, confuse
users far too much for their benefit, and that weighed with the
inevitable breakage that could ensure in CPAN and DarkPAN.

My perspective here is that, while this is not valuable syntax, it is
not in the way of anything. This means the concerns here are the mishaps
in the style of "$person's dog" v. the breakage that could ensue. I
would rather we minimize that single use-case rather than breaking
things. This is achieved by Chrysostomos' new warning.

Regarding Yves' comment on consistency, I think Ed showed it is already
inconsistent, so that door is already open.

On 11/22/2017 09​:42 PM, Zefram wrote​:

Ed Avis wrote​:

Might it be time to mark the old package separator as deprecated?
It's an the fuzzy boundary of what we consider deprecatable. It's rarely
used, and sane affected code can be easily updated to continue working.
We wouldn't be too bothered about the cute hacks like "isn't()" and
"don't {}". But it doesn't really stand in the way of actual improvement
to the Perl language or perl interpreter. The motivation of accidental
usage is mild; those bugs show up quickly.

-zefram

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 2, 2017

From @xenu

On Tue, 28 Nov 2017 14​:29​:14 +0200
Sawyer X <xsawyerx@​gmail.com> wrote​:

My perspective here is that, while this is not valuable syntax, it is
not in the way of anything. This means the concerns here are the mishaps
in the style of "$person's dog" v. the breakage that could ensue. I
would rather we minimize that single use-case rather than breaking
things. This is achieved by Chrysostomos' new warning.

Existence of ' package separator sometimes causes extremely misleading
error messages. For example, the following code crashes with "Bad name
after Int' at foo.pl line 10."​:

use Moose;

has erdef => (
  isa => 'Int',
  is => 'ro,
  default => sub { 1 }
);

has cxxc => (
  isa => 'Int',
  is => 'ro',
  default => sub { 1 }
);

Can you spot the real error?

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 2, 2017

From @cpansprout

On Fri, 01 Dec 2017 20​:03​:28 -0800, me@​xenu.pl wrote​:

Existence of ' package separator sometimes causes extremely misleading
error messages. For example, the following code crashes with "Bad name
after Int' at foo.pl line 10."​:

use Moose;

has erdef => (
isa => 'Int',
is => 'ro,
default => sub { 1 }
);

has cxxc => (
isa => 'Int',
is => 'ro',
default => sub { 1 }
);

Can you spot the real error?

Yes, I saw it immediately. But what you have pointed out is not a problem with ' per se. There is a logic error in toke.c (a separate bug), causing this error to suppress others. We can fix that.

--

Father Chrysostomos

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 4, 2017

From @cpansprout

On Fri, 01 Dec 2017 20​:03​:28 -0800, me xenu.pl wrote​:

On Tue, 28 Nov 2017 14​:29​:14 +0200
Sawyer X <xsawyerx gmail.com> wrote​:

My perspective here is that, while this is not valuable syntax, it is
not in the way of anything. This means the concerns here are the mishaps
in the style of "$person's dog" v. the breakage that could ensue. I
would rather we minimize that single use-case rather than breaking
things. This is achieved by Chrysostomos' new warning.

Existence of ' package separator sometimes causes extremely misleading
error messages. For example, the following code crashes with "Bad name
after Int' at foo.pl line 10."​:

use Moose;

has erdef => (
isa => 'Int',
is => 'ro,
default => sub { 1 }
);

has cxxc => (
isa => 'Int',
is => 'ro',
default => sub { 1 }
);

Can you spot the real error?

Try this example​:

use Moose;
our $subpackage = "Bar";

has erdef => (
  isa => "Int",
  is => "ro,
  default => sub { 1 }
);

has cxxc => (
  isa => "Foo​::$subpackage",
  is => "ro",
  default => sub { 1 }
);

It does the same unhelpful thing. (Bad name after Foo​::.) It’s not specific to '.

In bleadperl, as of commit 76b3530 (just committed), your example gives​:

Bareword found where operator expected at - line 10, near "isa => 'Int"
  (Might be a runaway multi-line '' string starting on line 5)
  (Do you need to predeclare isa?)
Bad name after Int' at - line 10.

That ‘Do you need to predeclare’ message is not helpful, but all I did was switch around the ‘Bareword found’ and ‘Bad name’ error messages.

--

Father Chrysostomos

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 4, 2017

From @xenu

On Mon, 04 Dec 2017 15​:47​:22 -0800
"Father Chrysostomos via RT" <perlbug-followup@​perl.org> wrote​:

In bleadperl, as of commit 76b3530 (just committed), your example gives​:

Bareword found where operator expected at - line 10, near "isa => 'Int"
(Might be a runaway multi-line '' string starting on line 5)
(Do you need to predeclare isa?)
Bad name after Int' at - line 10.

That �Do you need to predeclare� message is not helpful, but all I did was switch around the �Bareword found� and �Bad name� error messages.

Thank you, now it's much better!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant