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
Comments
From @epaCreated by @epaFor 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 Perl Info
|
From @cpansproutOn Mon Jun 17 04:15:00 2013, eda@waniasset.com wrote:
I would like to see that *un*deprecated. I see no reason why that -- Father Chrysostomos |
The RT System itself - Status changed from 'new' to 'open' |
From @davidnicolOn Mon, Jun 17, 2013 at 8:33 AM, Father Chrysostomos
Me too! And while we're on the subject, it should allow space between the |
From @cpansproutOn Tue Jun 25 18:12:46 2013, davidnicol@gmail.com wrote:
That would break << cmp <<, which currently works: $ perl -Xle 'print << cmp <<; ' -ea -e '' -eb -e '' -e '' -- Father Chrysostomos |
From @demerphqOn 17 June 2013 15:33, Father Chrysostomos via RT
FWIW I vote against this proposal. It should be an error. Yves -- |
From @tseeOn 06/26/2013 12:44 PM, demerphq wrote:
I'm with Yves. Also FWIW. --Steffen |
From @lizmatOn Jun 26, 2013, at 7:03 PM, Steffen Mueller <smueller@cpan.org> wrote:
Oddly enough, I'm with Yves on this one too :-) Liz |
From @rjbs* Father Chrysostomos via RT <perlbug-followup@perl.org> [2013-06-17T09:33:08]
I slept on this for a few nights, because you may well be correct that it -- |
From @cpansproutOn Wed Jun 26 16:32:27 2013, perl.p5p@rjbs.manxome.org wrote:
Can we at least leave it in (but deprecated) until it gets in the way of -- Father Chrysostomos |
From @epaIf 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? ______________________________________________________________________ |
From @ribasushiOn Thu, Jun 27, 2013 at 05:35:38AM +0000, Ed Avis wrote:
I think what FC is pointing out is: IFF a feature was deprecated because if was broken OR because it needed However there is no ground for removal of a deprecated feature, which A quote of the irc.perl.org#dbic-cabal topic seems relevant:
My 2c |
From @tseeOn 06/27/2013 09:12 AM, Peter Rabbitson wrote:
Ugh. Not true. It also means that people actually trust that we're How you value that benefit is, of course, up to you to decide. --Steffen |
From @demerphqOn 27 June 2013 09:12, Peter Rabbitson <rabbit-p5p@rabbit.us> wrote:
I think you are confusing "discouraged" and "deprecated". If a feature is something that should not be used in production code Once a feature is marked as deprecated we should rigorously follow Yves -- |
From @ribasushiI am taking this thread out of the RT queue. On Thu, Jun 27, 2013 at 09:44:02AM +0200, demerphq wrote:
No I am not.
We (and I mean most of the developers I run across) use the term In other words for most of us deprecations are a way for developers to
The warning is there so that the end user has time to run a cost benefit Cheers |
From @nwc10On Thu, Jun 27, 2013 at 05:56:36PM +1000, Peter Rabbitson wrote:
I don't agree with the absolute here. But I totally agree with the concern. a) The reasons for marking them as such are ambiguous, rather than clear
I see your point, but I think that you are contradicting yourself here. Also, given that there is no reliable timeframe on deprecation eliminations, 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 But the trade off is getting the balance right to make the end user pain I don't have an answer here, but I'm not convinced that the end-member I'm wondering if the least worst answer is that we have a policy of removing *) we may remove it two major releases after it is first deprecated Nicholas Clark |
From @ribasushiOn Thu, Jun 27, 2013 at 09:34:01AM +0100, Nicholas Clark wrote:
I dropped some context that was present in my original mail [1]. In it I
To summarize/clarify my position: An end-user has no right to complain
You know very well that this is not how the real world of PHBs work. The
These are all excellent guidelines (as long as 2 retains its bracketed 1) seems to be the case for the feature in question - namely <<''. It
This would be a reasonable timeline, except I still fail to see the urge Cheers [1] http://www.nntp.perl.org/group/perl.perl5.porters/2013/06/msg203778.html |
From @nwc10On Thu, Jun 27, 2013 at 06:54:57PM +1000, Peter Rabbitson wrote:
Thanks..
Agree with how reality inevitably pans out. But I wouldn't call that a cost I don't think that the timescale matters, other than "right now" versus
Yes, it is bugging me that removing things *feels* more like dogma than a) it's *marginally* harder to teach people a language with yet another The case of (IIRC) do subroutine syntax springs to mind. IIRC chromatic So no individual change is worth it. On its own. But the sum of quite a Nicholas Clark |
From @ribasushiOn Thu, Jun 27, 2013 at 10:56:13AM +0100, Nicholas Clark wrote:
This is precisely what I was trying to convey.
I thought this has already been addressed... While teaching it is
I don't think this applies... a quirk of a project is a quirk of a
Being 2 (or 4%) of the grammar, and being a special case of invocation
I actually agree with this in principle. It is the context of such I am specifically decrying "cleanup for the sake of cleanup" - when In other words - all I wanted to do is raise an objection against the What do you think? :) Cheers |
From @demerphqOn 27 June 2013 10:54, Peter Rabbitson <rabbit-p5p@rabbit.us> wrote:
The time to have that discussion is *before* the feature is deprecated. If there is not a sufficiently good reason to deprecate the feature What you are suggesting is that we can only remove deprecated features Frankly if I encountered a sufficiently long deprecated feature in Yves -- |
From @ribasushiOn Thu, Jun 27, 2013 at 12:26:16PM +0200, demerphq wrote:
I never made such a claim. Please reread my parts of the thread and try
I don't think so either ;)
Agreed (nor ever contested)
Precisely! The whole point is that this is not the case wrt <<"". Thanks for loudly agreeing with me ;) Cheers |
From @demerphqOn 27 June 2013 12:31, Peter Rabbitson <rabbit-p5p@rabbit.us> wrote:
No you did. You said people have a right to complain if we remove a deprecated Since we only mark things as deprecated for a reason what you are
So then how come you said people have a right to complain when we do
Well, just for the record, I dont think I am. For me simply wanting to cheers, -- |
From @ribasushiI omitted a bunch of text where you keep claiming I said things I never On Thu, Jun 27, 2013 at 12:57:16PM +0200, demerphq wrote:
Right, and this kind of "aesthetically driven breakage" is what prompted As I said elsewhere - it's "pumpking time". Note - not time for the Cheers |
From @demerphqOn 27 June 2013 13:08, Peter Rabbitson <rabbit-p5p@rabbit.us> wrote:
Dude, read your mails. You said: "An end user could very well complain that a feature was gone without a "I still fail to see the urge to break something without a clear You use "technical" as a metric to decide if someone has a worthy Now, if you want to join FC in arguing that a feature should be Yves |
From @ribasushiOn Thu, Jun 27, 2013 at 01:26:29PM +0200, demerphq wrote:
Correct - they have the right to complain.
Correct - I fail to see it.
You keep conflating "deprecated" with "gone". The whole point I am Consider my terminology: * Deprecated => may disappear down the road, warns loudly, but still there The transition between *these two states* is what I think we should "I want to have a shorter list of deprecated stuff" is *NOT* a technical
If someone (you or a new developer) decides to spend his tuits to
Could you expand what incident are you referring to?
The pumpking has spoken on *that* issue[1], there is nothing to argue
Correct - we are having this other argument now. The pumpking has not Cheers [1] http://www.nntp.perl.org/group/perl.perl5.porters/2013/06/msg203752.html |
From @LeontOn Mon, Jun 17, 2013 at 1:15 PM, Ed Avis <perlbug-followup@perl.org> wrote:
I think it may not be entirely obvious to the casual reader that this print <<; exit 0; And not about print <<END; Leon |
From @ikegamiOn Thu, Jun 27, 2013 at 7:39 AM, Peter Rabbitson <rabbit-p5p@rabbit.us>wrote:
As much as I like checking items off of lists, I can't picture someone "I don't want people to grow accustomed to long deprecation cycles." Yves is viewing deprecation as approval for removal. The technical merits |
From vadim.konovalov@alcatel-lucent.com
in reality - documentation will be opposite to be cleaned up: there will be regarding topic itself, Whether it was FMTYENTK or somewhere else I can't remember. Personaly, I would prefer not to have feature deprecated and removed, but Regards, |
From vadim.konovalov@alcatel-lucent.com
wow thanks for letting know, :) |
From @ap* Peter Rabbitson <rabbit-p5p@rabbit.us> [2013-06-27 09:15]:
Historically, there has been a problem in removing features that had The point of tension here, to which a solution would be welcome if you I.e. it’s fine for now if it keeps working in code that has already been That way, the investment of people who used it in the past is safe- I don’t think this is possible to achieve. The realm of the possible here is a spectrum, and your proposal lies at It’s not necessarily a one-dimensional spectrum, mind you. Moving toward The question is, what approaches can be taken to try to satisfy as much Regards, |
From @davidnicolOn Tue, Jun 25, 2013 at 10:43 PM, Father Chrysostomos via RT <
|
From @cpansproutOn Wed Jun 26 16:32:27 2013, perl.p5p@rjbs.manxome.org wrote:
In that case I have rerejected ticket #66686. -- Father Chrysostomos |
From @ribasushiOn Thu, Jun 27, 2013 at 09:44:13PM +0200, Aristotle Pagaltzis wrote:
Is this really the point of tension though? Let's take a much less Maybe the argument here is "but not everyone uses warnings", which is However what we have is an army of modules which unapologetically import This still leaves us with the problem of oneliners which are not Still my question stands - is the threat of new code using *visibly* Cheers |
From @demerphqOn 27 June 2013 20:59, Konovalov, Vadim (Vadim)** CTR **
I can see what you mean, but it is besides the point for me. The point I persist in the belief that any argument about whether a feature Its like veto politics, a perfect way to make it impossible to get Yves |
From @epa
Agreed, and further, if there is not a 'technical reason' (whatever that means) ______________________________________________________________________ |
From @rjbsThis is another of those situations that, I think, isn't really as straightforward as it might seem. * use of bare << to mean "" has been deprecated since 5.002 (1996-02) So, if we remove this behavior, something breaks, but the language is otherwise somehow Code that will break was either written before 1996, written without consulting the The benefit to weigh against these costs are: (1) the removal of a very small amount of code; (2) I find (3) to be the least compelling on its own. It's okay to be wrong about having deprecated Sometimes, it's good to take a nice long time to figure out the right answer. Sometimes, that I see no value in keeping "bare <<" heredocs around, other than avoiding the breakage of a -- |
From @cpansproutOn Sun Jun 30 20:31:15 2013, rjbs wrote:
For the record, there would be no code removal. It takes more code to -- Father Chrysostomos |
From @jonjensenI'd like to ask a simple question. Maybe I'm misunderstanding something obvious, but I don't see where/when this was *ever* Running Perl 5.18.0 from perlbrew: % ./heredoc-test.pl use strict; print <<END; The Perl 5.18.0 perlop man page says: <<EOF The terminating string may be either an identifier (a word), or some quoted text. An unquoted identifier works 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. Again, what am I missing? Where is this deprecation notice? If I hadn't come across this thread I would think there's Jon |
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* Running Perl 5.18.0 from perlbrew: % ./heredoc-test.pl use strict; print <<END; The Perl 5.18.0 perlop man page says: <<EOF The terminating string may be either an identifier (a word), or some quoted text. An unquoted identifier works 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. Again, what am I missing? Where is this deprecation notice? If I hadn't come across this thread I would think there's Jon |
From @jonjensenGoodness. If this really means literally <<"" vs. <<"END" then yeah, 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 |
From [Unknown Contact. See original ticket]Goodness. If this really means literally <<"" vs. <<"END" then yeah, 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 |
From @epaCould 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? |
From @petdanceOn Fri, 09 Jun 2017 08:40:55 -0700, ed wrote:
It's coming out in 5.28.0. See the new document perldeprecation. |
From @AbigailOn Fri, Jun 09, 2017 at 08:40:56AM -0700, Ed Avis via RT wrote:
This is already in blead: $ ./perl -Ilib -wE '<<;' All deprecations of which 5.26.0 say they will be gone in 5.28 are Abigail |
From @epaGreat, so the bug's status can change to 'pending release'. |
From @jkeenanOn Fri, 09 Jun 2017 16:21:00 GMT, ed wrote:
# 5.26.0 $ perl -v | head -2 | tail -1 $ perl -wE '<<;' # blead $ ./perl -Ilib -v | head -2 | tail -1 $ ./perl -Ilib -wE '<<;' -- |
@jkeenan - Status changed from 'open' to 'pending release' |
From @khwilliamsonThank 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 Perl 5.28.0 may be downloaded via: If you find that the problem persists, feel free to reopen this ticket. |
@khwilliamson - Status changed from 'pending release' to 'resolved' |
Migrated from rt.perl.org#118511 (status was 'resolved')
Searchable as RT118511$
The text was updated successfully, but these errors were encountered: