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

Use of bare << to mean <<"" is deprecated - make a hard error #13032

Closed
p5pRT opened this issue Jun 17, 2013 · 49 comments
Closed

Use of bare << to mean <<"" is deprecated - make a hard error #13032

p5pRT opened this issue Jun 17, 2013 · 49 comments

Comments

@p5pRT
Copy link
Collaborator

@p5pRT p5pRT commented Jun 17, 2013

Migrated from rt.perl.org#118511 (status was 'resolved')

Searchable as RT118511$

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 17, 2013

From @epa

Created by @epa

For a long time Perl has issued a warning

  Use of bare << to mean <<"" is deprecated

This has been deprecated for a very long time and it could now
be made a syntax error.

Perl Info

Flags:
    category=core
    severity=low

Site configuration information for perl 5.16.3:

Configured by Red Hat, Inc. at Fri May  3 12:10:03 UTC 2013.

Summary of my perl5 (revision 5 version 16 subversion 3) configuration:
   
  Platform:
    osname=linux, osvers=2.6.32-358.2.1.el6.x86_64, archname=x86_64-linux-thread-multi
    uname='linux buildvm-24.phx2.fedoraproject.org 2.6.32-358.2.1.el6.x86_64 #1 smp wed feb 20 12:17:37 est 2013 x86_64 x86_64 x86_64 gnulinux '
    config_args='-des -Doptimize=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4  -m64 -mtune=generic -Dccdlflags=-Wl,--enable-new-dtags -Dlddlflags=-shared -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4  -m64 -mtune=generic -Wl,-z,relro  -DDEBUGGING=-g -Dversion=5.16.3 -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
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=define, use64bitall=define, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic',
    cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
    ccversion='', gccversion='4.7.2 20121109 (Red Hat 4.7.2-8)', 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='gcc', ldflags =' -fstack-protector'
    libpth=/usr/local/lib64 /lib64 /usr/lib64
    libs=-lresolv -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc -lgdbm_compat
    perllibs=-lresolv -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
    libc=, so=so, useshrplib=true, libperl=libperl.so
    gnulibc_version='2.16'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,--enable-new-dtags -Wl,-rpath,/usr/lib64/perl5/CORE'
    cccdlflags='-fPIC', lddlflags='-shared -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wl,-z,relro '

Locally applied patches:
    


@INC for perl 5.16.3:
    /home/eda/lib/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.16.3:
    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:/usr/local/bin:/usr/bin:/sbin:/usr/sbin:/sbin:/usr/sbin
    PERL5LIB=/home/eda/lib/perl5/
    PERL_BADLANG (unset)
    SHELL=/bin/bash

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 17, 2013

From @cpansprout

On Mon Jun 17 04​:15​:00 2013, eda@​waniasset.com wrote​:

This is a bug report for perl from eda@​waniasset.com,
generated with the help of perlbug 1.39 running under perl 5.16.3.

-----------------------------------------------------------------
[Please describe your issue here]

For a long time Perl has issued a warning

Use of bare \<\< to mean \<\<"" is deprecated

This has been deprecated for a very long time and it could now
be made a syntax error.

I would like to see that *un*deprecated. I see no reason why that
syntax should cause any problems. It doesn’t make anything less
ambiguous to remove it. (On top of that, it looks nice!)

--

Father Chrysostomos

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 17, 2013

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

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 26, 2013

From @davidnicol

On Mon, Jun 17, 2013 at 8​:33 AM, Father Chrysostomos

I would like to see that *un*deprecated. I see no reason why that
syntax should cause any problems. It doesn’t make anything less
ambiguous to remove it. (On top of that, it looks nice!)

Me too! And while we're on the subject, it should allow space between the
angle
brackets and the bareword terminator.

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 26, 2013

From @cpansprout

On Tue Jun 25 18​:12​:46 2013, davidnicol@​gmail.com wrote​:

On Mon, Jun 17, 2013 at 8​:33 AM, Father Chrysostomos

I would like to see that *un*deprecated. I see no reason why that
syntax should cause any problems. It doesn’t make anything less
ambiguous to remove it. (On top of that, it looks nice!)

Me too! And while we're on the subject, it should allow space between the
angle
brackets and the bareword terminator.

That would break << cmp <<, which currently works​:

$ perl -Xle 'print << cmp <<; ' -ea -e '' -eb -e '' -e ''
-1
$ perl -Xle 'print << cmp <<; ' -eb -e '' -ea -e '' -e ''
1

--

Father Chrysostomos

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 26, 2013

From @demerphq

On 17 June 2013 15​:33, Father Chrysostomos via RT
<perlbug-followup@​perl.org> wrote​:

On Mon Jun 17 04​:15​:00 2013, eda@​waniasset.com wrote​:

This is a bug report for perl from eda@​waniasset.com,
generated with the help of perlbug 1.39 running under perl 5.16.3.

-----------------------------------------------------------------
[Please describe your issue here]

For a long time Perl has issued a warning

Use of bare \<\< to mean \<\<"" is deprecated

This has been deprecated for a very long time and it could now
be made a syntax error.

I would like to see that *un*deprecated. I see no reason why that
syntax should cause any problems. It doesn’t make anything less
ambiguous to remove it. (On top of that, it looks nice!)

FWIW I vote against this proposal. It should be an error.

Yves

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

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 26, 2013

From @tsee

On 06/26/2013 12​:44 PM, demerphq wrote​:

On 17 June 2013 15​:33, Father Chrysostomos via RT
<perlbug-followup@​perl.org> wrote​:

On Mon Jun 17 04​:15​:00 2013, eda@​waniasset.com wrote​:

This is a bug report for perl from eda@​waniasset.com,
generated with the help of perlbug 1.39 running under perl 5.16.3.
-----------------------------------------------------------------
[Please describe your issue here]

For a long time Perl has issued a warning

 Use of bare \<\< to mean \<\<"" is deprecated

This has been deprecated for a very long time and it could now
be made a syntax error.

I would like to see that *un*deprecated. I see no reason why that
syntax should cause any problems. It doesn’t make anything less
ambiguous to remove it. (On top of that, it looks nice!)

FWIW I vote against this proposal. It should be an error.

I'm with Yves. Also FWIW.

--Steffen

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 26, 2013

From @lizmat

On Jun 26, 2013, at 7​:03 PM, Steffen Mueller <smueller@​cpan.org> wrote​:

On 06/26/2013 12​:44 PM, demerphq wrote​:

On 17 June 2013 15​:33, Father Chrysostomos via RT
<perlbug-followup@​perl.org> wrote​:

On Mon Jun 17 04​:15​:00 2013, eda@​waniasset.com wrote​:

This is a bug report for perl from eda@​waniasset.com,
generated with the help of perlbug 1.39 running under perl 5.16.3.
-----------------------------------------------------------------
[Please describe your issue here]

For a long time Perl has issued a warning

Use of bare \<\< to mean \<\<"" is deprecated

This has been deprecated for a very long time and it could now
be made a syntax error.

I would like to see that *un*deprecated. I see no reason why that
syntax should cause any problems. It doesn’t make anything less
ambiguous to remove it. (On top of that, it looks nice!)

FWIW I vote against this proposal. It should be an error.

I'm with Yves. Also FWIW.

Oddly enough, I'm with Yves on this one too :-)

Liz

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 26, 2013

From @rjbs

* Father Chrysostomos via RT <perlbug-followup@​perl.org> [2013-06-17T09​:33​:08]

I would like to see that *un*deprecated. I see no reason why that
syntax should cause any problems. It doesn’t make anything less
ambiguous to remove it. (On top of that, it looks nice!)

I slept on this for a few nights, because you may well be correct that it
introduces no syntactical ambiguity, and because I do generally believe that 𝑑𝑒
𝑔𝑢𝑠𝑡𝑖𝑏𝑢𝑠 𝑛𝑜𝑛 𝑒𝑠𝑡 𝑑𝑖𝑠𝑝𝑢𝑡𝑎𝑛𝑑𝑢𝑚... but no. I think it's just the sort of
facepalmingly "straightforward" syntax that has no real value but to further
confuse the uninitiated. Thirty-two thousand eight hundred and nine
shibboleths are enough. We can do without restoring one more.

--
rjbs
(is your astral plane broken? "de gustibus non est disputandum")

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 27, 2013

From @cpansprout

On Wed Jun 26 16​:32​:27 2013, perl.p5p@​rjbs.manxome.org wrote​:

* Father Chrysostomos via RT <perlbug-followup@​perl.org> [2013-06-
17T09​:33​:08]

I would like to see that *un*deprecated. I see no reason why that
syntax should cause any problems. It doesn’t make anything less
ambiguous to remove it. (On top of that, it looks nice!)

I slept on this for a few nights, because you may well be correct that
it
introduces no syntactical ambiguity, and because I do generally
believe that 𝑑𝑒
𝑔𝑢𝑠𝑡𝑖𝑏𝑢𝑠 𝑛𝑜𝑛 𝑒𝑠𝑡 𝑑𝑖𝑠𝑝𝑢𝑡𝑎𝑛𝑑𝑢𝑚... but no. I
think it's just the sort of
facepalmingly "straightforward" syntax that has no real value but to
further
confuse the uninitiated. Thirty-two thousand eight hundred and nine
shibboleths are enough. We can do without restoring one more.

Can we at least leave it in (but deprecated) until it gets in the way of
a bug fix or new feature? Removing it *will* break working scripts.

--

Father Chrysostomos

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 27, 2013

From @epa

If it's not possible to change this deprecation to a hard error (after a decade or so of warning) for fear it will break working scripts, what hope is there of the deprecation-removal cycle working for anything?

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http​://www.symanteccloud.com
______________________________________________________________________

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 27, 2013

From @ribasushi

On Thu, Jun 27, 2013 at 05​:35​:38AM +0000, Ed Avis wrote​:

If it's not possible to change this deprecation to a hard error (after a decade or so of warning) for fear it will break working scripts, what hope is there of the deprecation-removal cycle working for anything?

I think what FC is pointing out is​:

IFF a feature was deprecated because if was broken OR because it needed
to free up syntax for something infinitely more consistent and/or useful -
then removal after an announced deprecation is fair game.

However there is no ground for removal of a deprecated feature, which
already issues warnings to such effect (i.e. newbies will not use such
features mistakenly). By removing stuff solely to "honor a promise" is
creating work for darkpan users with the sole benefit of pleasing
someone aesthetically.

A quote of the irc.perl.org#dbic-cabal topic seems relevant​:

deprecated modules get deleted when they cause a problem and not before

My 2c

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 27, 2013

From @tsee

On 06/27/2013 09​:12 AM, Peter Rabbitson wrote​:

However there is no ground for removal of a deprecated feature, which
already issues warnings to such effect (i.e. newbies will not use such
features mistakenly). By removing stuff solely to "honor a promise" is
creating work for darkpan users with the sole benefit of pleasing
someone aesthetically.

Ugh. Not true. It also means that people actually trust that we're
serious about deprecations.

How you value that benefit is, of course, up to you to decide.

--Steffen

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 27, 2013

From @demerphq

On 27 June 2013 09​:12, Peter Rabbitson <rabbit-p5p@​rabbit.us> wrote​:

On Thu, Jun 27, 2013 at 05​:35​:38AM +0000, Ed Avis wrote​:

If it's not possible to change this deprecation to a hard error (after a decade or so of warning) for fear it will break working scripts, what hope is there of the deprecation-removal cycle working for anything?

I think what FC is pointing out is​:

IFF a feature was deprecated because if was broken OR because it needed
to free up syntax for something infinitely more consistent and/or useful -
then removal after an announced deprecation is fair game.

However there is no ground for removal of a deprecated feature, which
already issues warnings to such effect (i.e. newbies will not use such
features mistakenly). By removing stuff solely to "honor a promise" is
creating work for darkpan users with the sole benefit of pleasing
someone aesthetically.

A quote of the irc.perl.org#dbic-cabal topic seems relevant​:

deprecated modules get deleted when they cause a problem and not before

My 2c

I think you are confusing "discouraged" and "deprecated".

If a feature is something that should not be used in production code
but is allowed then its use should be discouraged in the
documentation, and not marked as deprecated run time warning. If we
use the term "deprecated" to mean "discouraged" then the word
"deprecated" and the warnings it generate are meaningless and will be
ignored, and then there is no point in having them.

Once a feature is marked as deprecated we should rigorously follow
through, otherwise there is no point in having the warning at all. We
could manage all of this in the documentation.

Yves

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

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 27, 2013

From @ribasushi

I am taking this thread out of the RT queue.

On Thu, Jun 27, 2013 at 09​:44​:02AM +0200, demerphq wrote​:

On 27 June 2013 09​:12, Peter Rabbitson <rabbit-p5p@​rabbit.us> wrote​:

On Thu, Jun 27, 2013 at 05​:35​:38AM +0000, Ed Avis wrote​:

If it's not possible to change this deprecation to a hard error (after a decade or so of warning) for fear it will break working scripts, what hope is there of the deprecation-removal cycle working for anything?

I think what FC is pointing out is​:

IFF a feature was deprecated because if was broken OR because it needed
to free up syntax for something infinitely more consistent and/or useful -
then removal after an announced deprecation is fair game.

However there is no ground for removal of a deprecated feature, which
already issues warnings to such effect (i.e. newbies will not use such
features mistakenly). By removing stuff solely to "honor a promise" is
creating work for darkpan users with the sole benefit of pleasing
someone aesthetically.

A quote of the irc.perl.org#dbic-cabal topic seems relevant​:

deprecated modules get deleted when they cause a problem and not before

My 2c

I think you are confusing "discouraged" and "deprecated".

No I am not.

If a feature is something that should not be used in production code
but is allowed then its use should be discouraged in the
documentation, and not marked as deprecated run time warning. If we
use the term "deprecated" to mean "discouraged" then the word
"deprecated" and the warnings it generate are meaningless and will be
ignored, and then there is no point in having them.

We (and I mean most of the developers I run across) use the term
"deprecated" to mean "Marked as 'will disappear at any time in the
future, without further warnings' - do not complain when it is gone".

In other words for most of us deprecations are a way for developers to
disclaim complaints about future demolition work. I never treat them as
*promise* of demolition work. I suspect in your book this means I am
ignoring deprecations by treating them thusly?

Once a feature is marked as deprecated we should rigorously follow
through, otherwise there is no point in having the warning at all.

The warning is there so that the end user has time to run a cost benefit
analysis and decide when to deal with the issue - either immediately, or
when the inevitable finally comes. You have no right to make this
decision for others, unless you are paying for their time.

Cheers

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 27, 2013

From @nwc10

On Thu, Jun 27, 2013 at 05​:56​:36PM +1000, Peter Rabbitson wrote​:

I am taking this thread out of the RT queue.

On Thu, Jun 27, 2013 at 09​:44​:02AM +0200, demerphq wrote​:

If a feature is something that should not be used in production code
but is allowed then its use should be discouraged in the
documentation, and not marked as deprecated run time warning. If we
use the term "deprecated" to mean "discouraged" then the word
"deprecated" and the warnings it generate are meaningless and will be
ignored, and then there is no point in having them.

We (and I mean most of the developers I run across) use the term
"deprecated" to mean "Marked as 'will disappear at any time in the
future, without further warnings' - do not complain when it is gone".

In other words for most of us deprecations are a way for developers to
disclaim complaints about future demolition work. I never treat them as
*promise* of demolition work. I suspect in your book this means I am
ignoring deprecations by treating them thusly?

Once a feature is marked as deprecated we should rigorously follow
through, otherwise there is no point in having the warning at all.

I don't agree with the absolute here. But I totally agree with the concern.
If things are marked as deprecated but seemingly never removed, then

a) The reasons for marking them as such are ambiguous, rather than clear
b) People will ignore the desired intent of the warnings (to stop using this)

The warning is there so that the end user has time to run a cost benefit
analysis and decide when to deal with the issue - either immediately, or
when the inevitable finally comes. You have no right to make this
decision for others, unless you are paying for their time.

I see your point, but I think that you are contradicting yourself here.
Given that you already described the warnings as meaning "do not complain
when it is gone", then others should not be complaining if the deprecated
feature is pulled promptly.

Also, given that there is no reliable timeframe on deprecation eliminations,
it's not actually possible for anyone to perform a cost-benefit analysis
of whether to deal with it now or "at the time of removal", because without
a timeframe for the latter, it's impossible to calculate the correct
discount for future work. For calculation purposes, it would actually be
better to stick to a firm timescale, instead of deferring as long as
possible.

I know *why* things are deprecated, because (one of)

1) we think that they are going to get in the way of a net more useful thing
2) with hindsight, they shouldn't be part of the design
  (they add more in complexity than they deliver in benefits)
3) they are becoming impossible to maintain

But the trade off is getting the balance right to make the end user pain
of fixing less than the end user pain of not fixing, so that we keep (most)
of the end users.

I don't have an answer here, but I'm not convinced that the end-member
positions are correct.

I'm wondering if the least worst answer is that we have a policy of removing
things "not later than" a "long but bounded" time in the future. eg

*) we may remove it two major releases after it is first deprecated
*) we will remove it five major releases after it is first deprecated

Nicholas Clark

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 27, 2013

From @ribasushi

On Thu, Jun 27, 2013 at 09​:34​:01AM +0100, Nicholas Clark wrote​:

On Thu, Jun 27, 2013 at 05​:56​:36PM +1000, Peter Rabbitson wrote​:

I am taking this thread out of the RT queue.

On Thu, Jun 27, 2013 at 09​:44​:02AM +0200, demerphq wrote​:

If a feature is something that should not be used in production code
but is allowed then its use should be discouraged in the
documentation, and not marked as deprecated run time warning. If we
use the term "deprecated" to mean "discouraged" then the word
"deprecated" and the warnings it generate are meaningless and will be
ignored, and then there is no point in having them.

We (and I mean most of the developers I run across) use the term
"deprecated" to mean "Marked as 'will disappear at any time in the
future, without further warnings' - do not complain when it is gone".

In other words for most of us deprecations are a way for developers to
disclaim complaints about future demolition work. I never treat them as
*promise* of demolition work. I suspect in your book this means I am
ignoring deprecations by treating them thusly?

Once a feature is marked as deprecated we should rigorously follow
through, otherwise there is no point in having the warning at all.

I don't agree with the absolute here. But I totally agree with the concern.
If things are marked as deprecated but seemingly never removed, then

a) The reasons for marking them as such are ambiguous, rather than clear
b) People will ignore the desired intent of the warnings (to stop using this)

The warning is there so that the end user has time to run a cost benefit
analysis and decide when to deal with the issue - either immediately, or
when the inevitable finally comes. You have no right to make this
decision for others, unless you are paying for their time.

I see your point, but I think that you are contradicting yourself here.
Given that you already described the warnings as meaning "do not complain
when it is gone", then others should not be complaining if the deprecated
feature is pulled promptly.

I dropped some context that was present in my original mail [1]. In it I
said​:

IFF a feature was deprecated because if was broken OR because it needed
to free up syntax for something infinitely more consistent and/or useful -
then removal after an announced deprecation is fair game.

To summarize/clarify my position​: An end-user has no right to complain
that a deprecated feature got in the way of something and was removed.
An end user could very well complain that a feature was gone without a
technical reason (see below).

Also, given that there is no reliable timeframe on deprecation eliminations,
it's not actually possible for anyone to perform a cost-benefit analysis
of whether to deal with it now or "at the time of removal", because without
a timeframe for the latter, it's impossible to calculate the correct
discount for future work.

You know very well that this is not how the real world of PHBs work. The
usual cost-benefit analysis is framed roughly as "Alrighty, out of this
pile of technical debt, what do we have to do NOW and what can we do NOT
NOW"

I know *why* things are deprecated, because (one of)

1) we think that they are going to get in the way of a net more useful thing
2) with hindsight, they shouldn't be part of the design
(they add more in complexity than they deliver in benefits)
3) they are becoming impossible to maintain

These are all excellent guidelines (as long as 2 retains its bracketed
disclaimer)

1) seems to be the case for the feature in question - namely <<''. It
has already been deprecated as such. And its users (in this case FC)
conceeded that if a saner use comes along he will let it go. With all
that - what is the benefit of breaking his actual existing code now,
instead of when the use case for <<'' becomes clear?

But the trade off is getting the balance right to make the end user pain
of fixing less than the end user pain of not fixing, so that we keep (most)
of the end users.

I don't have an answer here, but I'm not convinced that the end-member
positions are correct.

I'm wondering if the least worst answer is that we have a policy of removing
things "not later than" a "long but bounded" time in the future. eg

*) we may remove it two major releases after it is first deprecated
*) we will remove it five major releases after it is first deprecated

This would be a reasonable timeline, except I still fail to see the urge
to break something without a clear technical need.

Cheers

[1] http​://www.nntp.perl.org/group/perl.perl5.porters/2013/06/msg203778.html

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 27, 2013

From @nwc10

On Thu, Jun 27, 2013 at 06​:54​:57PM +1000, Peter Rabbitson wrote​:

On Thu, Jun 27, 2013 at 09​:34​:01AM +0100, Nicholas Clark wrote​:

I see your point, but I think that you are contradicting yourself here.
Given that you already described the warnings as meaning "do not complain
when it is gone", then others should not be complaining if the deprecated
feature is pulled promptly.

I dropped some context that was present in my original mail [1]. In it I
said​:

IFF a feature was deprecated because if was broken OR because it needed
to free up syntax for something infinitely more consistent and/or useful -
then removal after an announced deprecation is fair game.

To summarize/clarify my position​: An end-user has no right to complain
that a deprecated feature got in the way of something and was removed.
An end user could very well complain that a feature was gone without a
technical reason (see below).

Thanks..

Also, given that there is no reliable timeframe on deprecation eliminations,
it's not actually possible for anyone to perform a cost-benefit analysis
of whether to deal with it now or "at the time of removal", because without
a timeframe for the latter, it's impossible to calculate the correct
discount for future work.

You know very well that this is not how the real world of PHBs work. The
usual cost-benefit analysis is framed roughly as "Alrighty, out of this
pile of technical debt, what do we have to do NOW and what can we do NOT
NOW"

Agree with how reality inevitably pans out. But I wouldn't call that a cost
benefit analysis. That's more triaging, or at least two thirds of triaging -
"what will die unless we intervene immediately" vs "what will still be
living if not treated right now".

I don't think that the timescale matters, other than "right now" versus
"sufficiently far in the future that it's not in this budget"

1) seems to be the case for the feature in question - namely <<''. It
has already been deprecated as such. And its users (in this case FC)
conceeded that if a saner use comes along he will let it go. With all
that - what is the benefit of breaking his actual existing code now,
instead of when the use case for <<'' becomes clear?

This would be a reasonable timeline, except I still fail to see the urge
to break something without a clear technical need.

Yes, it is bugging me that removing things *feels* more like dogma than
pragmatism. But this case, it's arguably also a language design issue, and a
maintenance issue. Bother of which is harder to quantify. ie

a) it's *marginally* harder to teach people a language with yet another
  special-case feature. (Or expect them to maintain code with it)
b) it's *marginally* harder to maintain the code codebase because the code
  to deal with the feature exists

The case of (IIRC) do subroutine syntax springs to mind. IIRC chromatic
calculated that 2% (or was it 4%) of the Perl grammar exists just to deal
with it. From a language-user point of view it's not getting in the way -
if you don't use it, it doesn't hurt you. But it's potentially one of the
"thousand cuts".

So no individual change is worth it. On its own. But the sum of quite a
few of them start to take things in the right direction. So I don't think
it's purely dogma to be removing things before they are *actively* in the
way. So there's a cost to any approach.

Nicholas Clark

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 27, 2013

From @ribasushi

On Thu, Jun 27, 2013 at 10​:56​:13AM +0100, Nicholas Clark wrote​:

On Thu, Jun 27, 2013 at 06​:54​:57PM +1000, Peter Rabbitson wrote​:

You know very well that this is not how the real world of PHBs work. The
usual cost-benefit analysis is framed roughly as "Alrighty, out of this
pile of technical debt, what do we have to do NOW and what can we do NOT
NOW"

Agree with how reality inevitably pans out. But I wouldn't call that a cost
benefit analysis. That's more triaging, or at least two thirds of triaging -
"what will die unless we intervene immediately" vs "what will still be
living if not treated right now".

I don't think that the timescale matters, other than "right now" versus
"sufficiently far in the future that it's not in this budget"

This is precisely what I was trying to convey.

1) seems to be the case for the feature in question - namely <<''. It
has already been deprecated as such. And its users (in this case FC)
conceeded that if a saner use comes along he will let it go. With all
that - what is the benefit of breaking his actual existing code now,
instead of when the use case for <<'' becomes clear?

This would be a reasonable timeline, except I still fail to see the urge
to break something without a clear technical need.

Yes, it is bugging me that removing things *feels* more like dogma than
pragmatism. But this case, it's arguably also a language design issue, and a
maintenance issue. Bother of which is harder to quantify. ie

a) it's *marginally* harder to teach people a language with yet another
special-case feature.

I thought this has already been addressed... While teaching it is
perfectly acceptable to gloss over anything deprecated. It is even
acceptable to gloss over *discouraged* practices (e.g. 2 arg open,
indirect invocation, etc)

(Or expect them to maintain code with it)

I don't think this applies... a quirk of a project is a quirk of a
project. I could take your statement and apply it to any codebase that
uses Devel​::Declare, or Perl5i or somesuch - it is reasonable to expect
an employee to get familiar with the local dialect of perl used... Or am
I missing something?

b) it's *marginally* harder to maintain the code codebase because the code
to deal with the feature exists

The case of (IIRC) do subroutine syntax springs to mind. IIRC chromatic
calculated that 2% (or was it 4%) of the Perl grammar exists just to deal
with it. From a language-user point of view it's not getting in the way -
if you don't use it, it doesn't hurt you. But it's potentially one of the
"thousand cuts".

Being 2 (or 4%) of the grammar, and being a special case of invocation
(thus likely having an effect on entersub or somesuch) - in any case -
there is *tangible* technical benefit of removing this. I do not believe
it would be reasonable to complain if this were removed during a
*related* encounter with this part of the parser/lexer/whathaveyou.

So no individual change is worth it. On its own. But the sum of quite a
few of them start to take things in the right direction. So I don't think
it's purely dogma to be removing things before they are *actively* in the
way. So there's a cost to any approach.

I actually agree with this in principle. It is the context of such
changes that bothers me.

I am specifically decrying "cleanup for the sake of cleanup" - when
someone takes time specifically to remove deprecated features for reason
no other than to "stick to the schedule". Yes, an argument can be made
that removing extra code now, will make it easier for the next
maintainer to work on this area. On the other hand one can make the
argument that cleanup with no plan prevents the currently-assigned-janitor
from seeing the big picture, thus preempting a much larger-scope cleanup
that would result if a particular new feature was held in mind.

In other words - all I wanted to do is raise an objection against the
perceived benefit of "cleanup for the sake of cleanup". I think both
sides have at this point exhausted and argumented their positions well
enough, thus it is "pmpking time".

What do you think? :)

Cheers

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 27, 2013

From @demerphq

On 27 June 2013 10​:54, Peter Rabbitson <rabbit-p5p@​rabbit.us> wrote​:

To summarize/clarify my position​: An end-user has no right to complain
that a deprecated feature got in the way of something and was removed.
An end user could very well complain that a feature was gone without a
technical reason (see below).

The time to have that discussion is *before* the feature is deprecated.

If there is not a sufficiently good reason to deprecate the feature
then it should not be deprecated.

What you are suggesting is that we can only remove deprecated features
when you and some group of unnamed individuals have approved the
reason for removal. I dont think that flies. Any such issues should be
raised when the features is proposed for deprecation. If the pumpking,
who has final decision on the matter, decides the item is deprecated
then that should be sufficient.

Frankly if I encountered a sufficiently long deprecated feature in
part of the code I tend to work on and it got in my way in the
slightest bit I would chainsaw it without question or even discussion,
and would not expect any come back on it.

Yves

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

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 27, 2013

From @ribasushi

On Thu, Jun 27, 2013 at 12​:26​:16PM +0200, demerphq wrote​:

What you are suggesting is that we can only remove deprecated features
when you and some group of unnamed individuals have approved the
reason for removal.

I never made such a claim. Please reread my parts of the thread and try
to see my message for what it is.

I dont think that flies.

I don't think so either ;)

Any such issues should be raised when the features is proposed for
deprecation. If the pumpking, who has final decision on the matter,
decides the item is deprecated then that should be sufficient.

Agreed (nor ever contested)

Frankly if I encountered a sufficiently long deprecated feature in
part of the code I tend to work on and it got in my way in the
slightest bit I would chainsaw it without question or even discussion,
and would not expect any come back on it.

Precisely! The whole point is that this is not the case wrt <<"".

Thanks for loudly agreeing with me ;)

Cheers

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 27, 2013

From @demerphq

On 27 June 2013 12​:31, Peter Rabbitson <rabbit-p5p@​rabbit.us> wrote​:

On Thu, Jun 27, 2013 at 12​:26​:16PM +0200, demerphq wrote​:

What you are suggesting is that we can only remove deprecated features
when you and some group of unnamed individuals have approved the
reason for removal.

I never made such a claim. Please reread my parts of the thread and try
to see my message for what it is.

No you did.

You said people have a right to complain if we remove a deprecated
feature without a technical reason.

Since we only mark things as deprecated for a reason what you are
essentially arguing is that the complainers get final decision on
whether the reason is good enough.

I dont think that flies.

I don't think so either ;)

Any such issues should be raised when the features is proposed for
deprecation. If the pumpking, who has final decision on the matter,
decides the item is deprecated then that should be sufficient.

Agreed (nor ever contested)

So then how come you said people have a right to complain when we do
what the pumpking said we [cs]hould?

Frankly if I encountered a sufficiently long deprecated feature in
part of the code I tend to work on and it got in my way in the
slightest bit I would chainsaw it without question or even discussion,
and would not expect any come back on it.

Precisely! The whole point is that this is not the case wrt <<"".

Thanks for loudly agreeing with me ;)

Well, just for the record, I dont think I am. For me simply wanting to
clean up the documentation for here docs would be sufficient
justification to remove the deprecated feature. Indeed, simply wanting
to whittle down the list of deprecated features would be.

cheers,
Yves

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

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 27, 2013

From @ribasushi

I omitted a bunch of text where you keep claiming I said things I never
said (and Nicholas seemed to understand what I meant from the get-go)

On Thu, Jun 27, 2013 at 12​:57​:16PM +0200, demerphq wrote​:

For me simply wanting to clean up the documentation for here docs
would be sufficient justification to remove the deprecated feature.
Indeed, simply wanting to whittle down the list of deprecated features
would be.

Right, and this kind of "aesthetically driven breakage" is what prompted
me to participate in this thread in the first place.

As I said elsewhere - it's "pumpking time". Note - not time for the
pumpking to reevaluate a completed deprecation, but for the pumpking to
clarify whether aesthetical demolition is a tenable way forward.

Cheers

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 27, 2013

From @demerphq

On 27 June 2013 13​:08, Peter Rabbitson <rabbit-p5p@​rabbit.us> wrote​:

I omitted a bunch of text where you keep claiming I said things I never
said (and Nicholas seemed to understand what I meant from the get-go)

Dude, read your mails. You said​:

"An end user could very well complain that a feature was gone without a
technical reason (see below)."

"I still fail to see the urge to break something without a clear
technical need."

You use "technical" as a metric to decide if someone has a worthy
reason to remove something. I posit that *any* deprecation is due to
technical reasons and as such the only way that your position makes
sense is to read it as implying that you get to decide if the reason
is technical enough. Which IMO doesnt fly. The time to make arguments
like that is when the feature is deprecated. Not when random developer
decides to use their volunteer tuits to remove something we said they
could remove. I would be really pissed if some developer decided to
contribute their time and remove a bunch of deprecated features and
you whined that there wasnt a good enough reason. I dont want
developers to be discouraged doing what we already told them they
could do. (As in been there, done that, it wasn't fun, and I'd like to
make sure it doesnt happen to other people.)

Now, if you want to join FC in arguing that a feature should be
*un*deprecated that is fine, go ahead. But that is an entirely
different argument to you having the right to complain if I remove
something we all have already agreed can and should be removed.

Yves

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 27, 2013

From @ribasushi

On Thu, Jun 27, 2013 at 01​:26​:29PM +0200, demerphq wrote​:

On 27 June 2013 13​:08, Peter Rabbitson <rabbit-p5p@​rabbit.us> wrote​:

I omitted a bunch of text where you keep claiming I said things I never
said (and Nicholas seemed to understand what I meant from the get-go)

Dude, read your mails. You said​:

"An end user could very well complain that a feature was gone without a
technical reason (see below)."

Correct - they have the right to complain.

"I still fail to see the urge to break something without a clear
technical need."

Correct - I fail to see it.

You use "technical" as a metric to decide if someone has a worthy
reason to remove something. I posit that *any* deprecation is due to
technical reasons and as such the only way that your position makes
sense is to read it as implying that you get to decide if the reason
is technical enough.

You keep conflating "deprecated" with "gone". The whole point I am
trying to raise is that this is ridiculous.

Consider my terminology​:

* Deprecated => may disappear down the road, warns loudly, but still there
* Gone => compile time error

The transition between *these two states* is what I think we should
require a technical reason for.

"I want to have a shorter list of deprecated stuff" is *NOT* a technical
reason. It is a moronic reason.

Which IMO doesnt fly. The time to make arguments
like that is when the feature is deprecated. Not when random developer
decides to use their volunteer tuits to remove something we said they
could remove. I would be really pissed if some developer decided to
contribute their time and remove a bunch of deprecated features and
you whined that there wasnt a good enough reason.

If someone (you or a new developer) decides to spend his tuits to
"shorten the deprecation list" - yes I will "whine". And until rjbs says
otherwise I damn well will continue to do so.

I dont want developers to be discouraged doing what we already told
them they could do. (As in been there, done that, it wasn't fun, and
I'd like to make sure it doesnt happen to other people.)

Could you expand what incident are you referring to?

Now, if you want to join FC in arguing that a feature should be
*un*deprecated that is fine, go ahead.

The pumpking has spoken on *that* issue[1], there is nothing to argue
about.

But that is an entirely different argument to you having the right to
complain if I remove something we all have already agreed can and
should be removed.

Correct - we are having this other argument now. The pumpking has not
ruled on *this* argument.

Cheers

[1] http​://www.nntp.perl.org/group/perl.perl5.porters/2013/06/msg203752.html

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 27, 2013

From @Leont

On Mon, Jun 17, 2013 at 1​:15 PM, Ed Avis <perlbug-followup@​perl.org> wrote​:

For a long time Perl has issued a warning

Use of bare \<\< to mean \<\<"" is deprecated

This has been deprecated for a very long time and it could now
be made a syntax error.

I think it may not be entirely obvious to the casual reader that this
discussion is about

  print <<;
  Hello world

  exit 0;

And not about

  print <<END;
  Hello world
  END
  exit 0;

Leon

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 27, 2013

From @ikegami

On Thu, Jun 27, 2013 at 7​:39 AM, Peter Rabbitson <rabbit-p5p@​rabbit.us>wrote​:

"I want to have a shorter list of deprecated stuff" is *NOT* a technical
reason. It is a moronic reason.

As much as I like checking items off of lists, I can't picture someone
wanting that.

"I don't want people to grow accustomed to long deprecation cycles."
"I want the things we agreed should be removed to be removed."

Yves is viewing deprecation as approval for removal. The technical merits
have already been evaluated. The decision to break code has already been
made.

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 27, 2013

From vadim.konovalov@alcatel-lucent.com

From​: demerphq
For me simply wanting to
clean up the documentation for here docs would be sufficient
justification to remove the deprecated feature. Indeed, simply wanting
to whittle down the list of deprecated features would be.

in reality - documentation will be opposite to be cleaned up​: there will be
"starting from version x.y.z this is now differently", how thoroughly currently is.

regarding topic itself,
my feeling of reading docs some 15th years ago was that its absolutely
fine to omit double quotes and this is treated as double quotes.

Whether it was FMTYENTK or somewhere else I can't remember.

Personaly, I would prefer not to have feature deprecated and removed, but
in case it will be - ok, let it be.....

Regards,
Vadim.

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 27, 2013

From vadim.konovalov@alcatel-lucent.com

From​: Leon Timmermans
I think it may not be entirely obvious to the casual reader that this
discussion is about

print <<;
Hello world

exit 0;

And not about

print <<END;
Hello world
END
exit 0;

wow

thanks for letting know, :)
I wish I see the message couple of minutes earlier :)​:)

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 27, 2013

From @ap

* Peter Rabbitson <rabbit-p5p@​rabbit.us> [2013-06-27 09​:15]​:

By removing stuff solely to "honor a promise" is creating work for
darkpan users with the sole benefit of pleasing someone aesthetically.

A quote of the irc.perl.org#dbic-cabal topic seems relevant​:

deprecated modules get deleted when they cause a problem and not
before

Historically, there has been a problem in removing features that had
been marked deprecated for so long that people stopped caring about
their status as deprecated.

The point of tension here, to which a solution would be welcome if you
can propose one, is this​: is there a way to extinguish its use in newly
written code?

I.e. it’s fine for now if it keeps working in code that has already been
written – we don’t want to break anyone’s existing stuff needlessly. At
the same time, in the ideal case, not a single new use of this feature
would be introduced to the world anywhere.

That way, the investment of people who used it in the past is safe-
guarded until such time as it gets in the way – but, at the same time,
its eventual removal is not jeopardised by the length of time between
the moments of deprecation and removal due to continuing increase in its
use. In the ideal case, the moment something is marked deprecated, the
maximum cost of its removal is frozen at that point in time.

I don’t think this is possible to achieve.

The realm of the possible here is a spectrum, and your proposal lies at
the very end on one side of it. The other extreme in this spectrum is
not (to my mind) a reasonable position, but while the one you occupy is,
I don’t know that it’s necessarily the most reasonable one on the entire
spectrum.

It’s not necessarily a one-dimensional spectrum, mind you. Moving toward
Yves’ end is one way to have a stabilising effect on the cost of removal
but not necessarily the only solution.

The question is, what approaches can be taken to try to satisfy as much
of both criteria as possible? (I.e., maximise the safety margin for old
users while suppressing further cost from accruing against its removal.)

Regards,
--
Aristotle Pagaltzis // <http​://plasmasturm.org/>

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 27, 2013

From @davidnicol

On Tue, Jun 25, 2013 at 10​:43 PM, Father Chrysostomos via RT <
perlbug-followup@​perl.org> wrote​:

On Tue Jun 25 18​:12​:46 2013, davidnicol@​gmail.com wrote​:

Me too! And while we're on the subject, it should allow space between the
angle brackets and the bareword terminator.

That would break << cmp <<, which currently works​:

$ perl -Xle 'print << cmp <<; ' -ea -e '' -eb -e '' -e ''
-1
$ perl -Xle 'print << cmp <<; ' -eb -e '' -ea -e '' -e ''
1

I think that's what you said the last time, too, so I had the patch
special-case all
the bareword infix operators, including eq, lt, gt, ge, le as well as cmp.

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 27, 2013

From @cpansprout

On Wed Jun 26 16​:32​:27 2013, perl.p5p@​rjbs.manxome.org wrote​:

* Father Chrysostomos via RT <perlbug-followup@​perl.org> [2013-06-
17T09​:33​:08]

I would like to see that *un*deprecated. I see no reason why that
syntax should cause any problems. It doesn’t make anything less
ambiguous to remove it. (On top of that, it looks nice!)

I slept on this for a few nights, because you may well be correct that
it
introduces no syntactical ambiguity, and because I do generally
believe that 𝑑𝑒
𝑔𝑢𝑠𝑡𝑖𝑏𝑢𝑠 𝑛𝑜𝑛 𝑒𝑠𝑡 𝑑𝑖𝑠𝑝𝑢𝑡𝑎𝑛𝑑𝑢𝑚... but no. I
think it's just the sort of
facepalmingly "straightforward" syntax that has no real value but to
further
confuse the uninitiated. Thirty-two thousand eight hundred and nine
shibboleths are enough. We can do without restoring one more.

In that case I have rerejected ticket #66686.

--

Father Chrysostomos

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 27, 2013

From @ribasushi

On Thu, Jun 27, 2013 at 09​:44​:13PM +0200, Aristotle Pagaltzis wrote​:

* Peter Rabbitson <rabbit-p5p@​rabbit.us> [2013-06-27 09​:15]​:

By removing stuff solely to "honor a promise" is creating work for
darkpan users with the sole benefit of pleasing someone aesthetically.

A quote of the irc.perl.org#dbic-cabal topic seems relevant​:

deprecated modules get deleted when they cause a problem and not
before

Historically, there has been a problem in removing features that had
been marked deprecated for so long that people stopped caring about
their status as deprecated.

The point of tension here, to which a solution would be welcome if you
can propose one, is this​: is there a way to extinguish its use in newly
written code?

Is this really the point of tension though? Let's take a much less
obscure example​: a user buys a fresh book about perl and proceeds using
the shiny ~~ syntax. A set of loud warnings is emitted. If the user
proceeds writing code *despite* these warnings - is it really anyone
elses problem at this point...?

Maybe the argument here is "but not everyone uses warnings", which is
somewhat true. In an ideal world lexical warnings would be a tri-state,
with some warnings (deprecation, and reeeeeally ominous ones) being on
by default, and others being off by default, with the usual control with
use/no warnings. We don't have that.

However what we have is an army of modules which unapologetically import
pragmas into the callers namespace. So many in fact that it is becoming
increasingly unlikely that new code will not get warnings implicitly
turned on in many parts of the source.

This still leaves us with the problem of oneliners which are not
instrumented wrt deprecation warnings. I concede I do not have a good
solution for this, and as such chalking this up for "the cost of doing
business" seems the only solutions.

Still my question stands - is the threat of new code using *visibly*
deprecated features really that severe...?

Cheers

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 28, 2013

From @demerphq

On 27 June 2013 20​:59, Konovalov, Vadim (Vadim)** CTR **
<vadim.konovalov@​alcatel-lucent.com> wrote​:

From​: demerphq
For me simply wanting to
clean up the documentation for here docs would be sufficient
justification to remove the deprecated feature. Indeed, simply wanting
to whittle down the list of deprecated features would be.

in reality - documentation will be opposite to be cleaned up​: there will be
"starting from version x.y.z this is now differently", how thoroughly currently is.

I can see what you mean, but it is besides the point for me. The point
for me is that "technical reason" is poorly defined, such that one can
consider "simplify documentation" as technical, or not, as suits ones
preferences and biases. Which for me utterly undermines its use in
determining whether a deprecated feature should actually be removed.

I persist in the belief that any argument about whether a feature
should be removed or not should be determined *prior* to deprecation.
Deprecation means "this will be removed", not "maybe at some point in
the future we will find a reason to remove this so we are marking it
as deprecated now so that once we have the argument about whether
there is a good reason for removing it or not we can". The latter to
me is not a framework for getting stuff done.

Its like veto politics, a perfect way to make it impossible to get
anything done.

Yves

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 28, 2013

From @epa

I persist in the belief that any argument about whether a feature
should be removed or not should be determined *prior* to deprecation.

Agreed, and further, if there is not a 'technical reason' (whatever that means)
for removing it then it should not be marked as deprecated.

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http​://www.symanteccloud.com
______________________________________________________________________

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jul 1, 2013

From @rjbs

This is another of those situations that, I think, isn't really as straightforward as it might seem.
Here are some facts and observations, carelessly mingled​:

* use of bare << to mean "" has been deprecated since 5.002 (1996-02)
* starting then, it warned under "use warnings"
* starting it 5.12.0, it warned even without warnings requested (2010-04)
* when we deprecate things, we do it because we have a reason to actually remove it
* if we just think it's a bad idea, we "discourage" it instead
* use of bare << to mean "" has been *deprecated* since 5.002 (1996-02)
* ... but this discourage/deprecate distinction is a recent innovation
* records of the discussion of this deprecation, if any, are not easy to find
* ...but we know that we're not talking about dropping this behavior to make room for another
* rjbs has acknowledged thinking that this is a nasty piece of syntax, which will lead to
confusion
* somewhere, out there, there is code that will be busted if this code is removed

So, if we remove this behavior, something breaks, but the language is otherwise somehow
better. What's the actual tradeoff?

Code that will break was either written before 1996, written without consulting the
documentation, or written despite the documentation's warnings. It doesn't "use warnings" or
nobody is looking at its warning output. It isn't running on perl v5.12.0 or later, or "no
warnings" is there to shut up the warnings. So, the code that will break will be code that
expressly turned off warnings, or is being run ignoring the warnings, or is being upgraded from
5.10.x (or earlier) to 5.20.x directly, meaning a minimum of five years between releases used.
The solution in all cases is to replace << with <<""

The benefit to weigh against these costs are​: (1) the removal of a very small amount of code; (2)
the removal of a very small amount of documentation; (3) the proof that when we say
"deprecated," we mean it really will go away; (4) the resolution of a pending deprecation, which
otherwise will float in the air.

I find (3) to be the least compelling on its own. It's okay to be wrong about having deprecated
something. We can take as long as we like. It's more compelling in conjunction with (4). How
often are we going to have this conversation about bare <<? We just had it two years ago​:
http​://www.nntp.perl.org/group/perl.perl5.porters/2009/06/msg147438.html

Sometimes, it's good to take a nice long time to figure out the right answer. Sometimes, that
answer needs to come so that there is no more lingering question. It's an issue of keeping the
number of open questions low.

I see no value in keeping "bare <<" heredocs around, other than avoiding the breakage of a
presumably small amount of code that, frankly, has had every opportunity to reform. There is
no future in which I see the feature being appreciated and spared from the looming threat of
removal. We should put it out of its misery and move on, freeing up discussion time for things
of greater value.

--
rjbs

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jul 1, 2013

From @cpansprout

On Sun Jun 30 20​:31​:15 2013, rjbs wrote​:

(1) the removal of a
very small amount of code;

For the record, there would be no code removal. It takes more code to
prevent << from working than to allow it.

--

Father Chrysostomos

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jul 11, 2013

From @jonjensen

I'd like to ask a simple question. Maybe I'm misunderstanding something obvious, but I don't see where/when this was *ever*
deprecated or any warnings issued. Yes, Perl Best Practices proclaimed that double-quoting better showed intent. But I've
never seen any deprecation warning, or anything in the docs that says this is deprecated.

Running Perl 5.18.0 from perlbrew​:

% ./heredoc-test.pl
Version=5.018000
Here's a quote.
% cat heredoc-test.pl
#!/bin/env perl

use strict;
use warnings;

print <<END;
Version=$]
Here's a quote.
END

The Perl 5.18.0 perlop man page says​:

  <<EOF
  A line-oriented form of quoting is based on the shell "here-document" syntax. Following a "<<" you specify a
string to terminate the quoted material, and all lines following the current line down to the terminating string are the value
of the item.

  The terminating string may be either an identifier (a word), or some quoted text. An unquoted identifier works
like double quotes. There may not be a space between the "<<" and the identifier, unless the identifier is explicitly quoted.
(If you put a space it will be treated as a null identifier, which is valid, and matches the first empty line.) The
terminating string must appear by itself (unquoted and with no surrounding whitespace) on the terminating line.

No mention of deprecation anywhere that I can see.

What am I missing?

If it had really been warned about back to Perl 5.12, and if it really simplifies the grammar, I wouldn't mind it being gone.
But it will definitely break a ton of code. At least it's easy to fix, though. Yes according to Father Chrysostomos' last
comment, there's no internal code simplification waiting as a reward for all the breakage.

Again, what am I missing? Where is this deprecation notice? If I hadn't come across this thread I would think there's
absolutely nothing wrong with bareword heredocs except that Damian Conway's aesthetic preference was to avoid them. I work
with other Perl programmers who likewise have never heard of this.

Jon

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jul 11, 2013

From [Unknown Contact. See original ticket]

I'd like to ask a simple question. Maybe I'm misunderstanding something obvious, but I don't see where/when this was *ever*
deprecated or any warnings issued. Yes, Perl Best Practices proclaimed that double-quoting better showed intent. But I've
never seen any deprecation warning, or anything in the docs that says this is deprecated.

Running Perl 5.18.0 from perlbrew​:

% ./heredoc-test.pl
Version=5.018000
Here's a quote.
% cat heredoc-test.pl
#!/bin/env perl

use strict;
use warnings;

print <<END;
Version=$]
Here's a quote.
END

The Perl 5.18.0 perlop man page says​:

  <<EOF
  A line-oriented form of quoting is based on the shell "here-document" syntax. Following a "<<" you specify a
string to terminate the quoted material, and all lines following the current line down to the terminating string are the value
of the item.

  The terminating string may be either an identifier (a word), or some quoted text. An unquoted identifier works
like double quotes. There may not be a space between the "<<" and the identifier, unless the identifier is explicitly quoted.
(If you put a space it will be treated as a null identifier, which is valid, and matches the first empty line.) The
terminating string must appear by itself (unquoted and with no surrounding whitespace) on the terminating line.

No mention of deprecation anywhere that I can see.

What am I missing?

If it had really been warned about back to Perl 5.12, and if it really simplifies the grammar, I wouldn't mind it being gone.
But it will definitely break a ton of code. At least it's easy to fix, though. Yes according to Father Chrysostomos' last
comment, there's no internal code simplification waiting as a reward for all the breakage.

Again, what am I missing? Where is this deprecation notice? If I hadn't come across this thread I would think there's
absolutely nothing wrong with bareword heredocs except that Damian Conway's aesthetic preference was to avoid them. I work
with other Perl programmers who likewise have never heard of this.

Jon

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jul 11, 2013

From @jonjensen

Goodness. If this really means literally <<"" vs. <<"END" then yeah,
ignore my comment!

https://rt-archive.perl.org/perl5/Ticket/Display.html?id=118511#txn-1228753

Sorry for the misunderstanding. I'm commenting on the blog post that
misled me here​: http​://perlmaven.com/bare-here-documents-are-deprecated

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jul 11, 2013

From [Unknown Contact. See original ticket]

Goodness. If this really means literally <<"" vs. <<"END" then yeah,
ignore my comment!

https://rt-archive.perl.org/perl5/Ticket/Display.html?id=118511#txn-1228753

Sorry for the misunderstanding. I'm commenting on the blog post that
misled me here​: http​://perlmaven.com/bare-here-documents-are-deprecated

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 9, 2017

From @epa

Could the perl5-porters review this bug please? It's now a few years later, meaning even more years have passed since << for <<"" was first deprecated. Surely time to remove it now?

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 9, 2017

From @petdance

On Fri, 09 Jun 2017 08​:40​:55 -0700, ed wrote​:

Could the perl5-porters review this bug please? It's now a few years
later, meaning even more years have passed since << for <<"" was first
deprecated. Surely time to remove it now?

It's coming out in 5.28.0.

See the new document perldeprecation.

https://metacpan.org/pod/release/XSAWYERX/perl-5.26.0/pod/perldeprecation.pod#Bare-here-document-terminators

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 9, 2017

From @Abigail

On Fri, Jun 09, 2017 at 08​:40​:56AM -0700, Ed Avis via RT wrote​:

Could the perl5-porters review this bug please? It's now a few years later, meaning even more years have passed since << for <<"" was first deprecated. Surely time to remove it now?

This is already in blead​:

  $ ./perl -Ilib -wE '<<;'
  Use of bare << to mean <<"" is forbidden at -e line 1.
  $

All deprecations of which 5.26.0 say they will be gone in 5.28 are
gone in blead.

Abigail

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 9, 2017

From @epa

Great, so the bug's status can change to 'pending release'.

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 9, 2017

From @jkeenan

On Fri, 09 Jun 2017 16​:21​:00 GMT, ed wrote​:

Great, so the bug's status can change to 'pending release'.

# 5.26.0

$ perl -v | head -2 | tail -1
This is perl 5, version 26, subversion 0 (v5.26.0) built for x86_64-linux

$ perl -wE '<<;'
Use of bare << to mean <<"" is deprecated. Its use will be fatal in Perl 5.28 at -e line 1.
Can't find string terminator "" anywhere before EOF at -e line 1.

# blead

$ ./perl -Ilib -v | head -2 | tail -1
This is perl 5, version 27, subversion 1 (v5.27.1 (v5.27.0-279-g7ad910c)) built for x86_64-linux

$ ./perl -Ilib -wE '<<;'
Use of bare << to mean <<"" is forbidden at -e line 1.

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

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 9, 2017

@jkeenan - Status changed from 'open' to 'pending release'

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 23, 2018

From @khwilliamson

Thank you for filing this report. You have helped make Perl better.

With the release yesterday of Perl 5.28.0, this and 185 other issues have been
resolved.

Perl 5.28.0 may be downloaded via​:
https://metacpan.org/release/XSAWYERX/perl-5.28.0

If you find that the problem persists, feel free to reopen this ticket.

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 23, 2018

@khwilliamson - Status changed from 'pending release' to 'resolved'

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
You can’t perform that action at this time.