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
inward goto deprecation has no removal date #16275
Comments
From zefram@fysh.orgCreated by zefram@fysh.orgJumping into a block with goto is rightly deprecated: $ perl -lwe 'goto FOO; while(rand(1) > 2) { FOO: print 22; }' But that warning message is missing a bit: when will this deprecated Perl Info
|
From @cpansproutOn Thu, 23 Nov 2017 10:11:23 -0800, zefram@fysh.org wrote:
In <20170111060624.1223.qmail@lists-nntp.develooper.com> I wrote:
Sawyer responded, in <096e5596-a40c-0615-c5af-0e3718e2c7b0@gmail.com>:
In response, Abigail made this commit: commit dc6e8de There's an objection to fatalizing jumping into a construct. I never got around to starting a new thread, but that is what you have done. Can someone respond to my words above? -- Father Chrysostomos |
The RT System itself - Status changed from 'new' to 'open' |
From zefram@fysh.orgThe problems with inward gotos are bigger than you indicated. That it $ perl -lwe 'goto FOO; foreach(1,2) { FOO: print $_; }' We could `fix' [perl #74764] by making jumps into "given" fail this No, inward goto only makes sense where the "inward" part is a sham. $ perl -lwe 'my $i = 0; if(0) { RESTART: print "restarted"; } print "beginning process with i=$i"; goto RESTART unless $i++; print "done";' Say what? The label's right there! Inside the block for that "if" that I actually reported this as a bug, way back in 2000 in the pre-RT Unreachable code elimination is a good thing. But if code has a label Unfortunately I don't have a copy of any substantive reply to this, and Fixing this would indeed be troublesome. The easy bit would be to A lot of this comes down to the very dynamic way in which perl handles I have periodically had thoughts of implementing a "true goto" as a It's also worth comparing goto against our treatment of C's "switch" All in all, inward gotos don't fit into the language. They don't Inward goto has been deprecated for long enough that it should be fine to -zefram |
From @arcFather Chrysostomos via RT <perlbug-followup@perl.org> wrote:
I didn't realise this at the time the deprecation was reprieved, but perl -e 'goto X; meth { X: }' See https://rt.perl.org/Public/Bug/Display.html?id=130936 for details If we can't find a reasonable way to fix cases like those, I think we -- |
From @cpansproutOn Fri, 24 Nov 2017 02:56:04 -0800, zefram@fysh.org wrote:
I would be all in favour of that.
That is all documented behaviour. If it helps, we could change the wording of the documentation (in perlfunc) from: It also can't be used to go to: Using C<goto> to jump into a construct that is otherwise unreachable is not
But in those few cases where it does work (if/when), it causes no harm, and allows some code to be written more straightforwardly. My particular case is a long if/else chain. Sometimes, in a block preceding that if/else chain, it is determined ahead of time which if-block we will end up in, so a ‘goto’ allows for a (relatively) quick short-circuit. Yes, it’s true that I could rewrite the code some other way (skip the goto, use a hash of subs, etc.), but then it would be slower. (I could also write in my module’s documentation: ‘Perl 5.26.0 and lower recommended, as later versions are slower’, but I don’t think anybody wants that.)
I don’t think this would be at all unreasonable. But I think that having a goto-LABEL that can jump into simple blocks and dies for other constructs is a reasonable compromise.
For this reason, I’ve never really seen the point of Perl’s ‘given’. It offers no new features and saves typing a few characters. But this is actually quite irrelevant to goto.
I fail to see how inward goto is all that different from goto-&sub and list assignment to state(). eval { goto &sub } used to crash. Since it wasn’t easy to implement properly, it was made an error. Still, goto &sub is useful. state assignment was made an error in those cases where its behaviour hadn’t been decided. The few cases in which it will work are still useful, even without the full-blown state() feature that we could have. Similarly, using goto-LABEL to jump into if/when blocks is useful, if even the more weird constructs don’t work, or even crash. Let’s just forbid the crashing cases. I realize you will probably reject my reasoning. But I hope you will appreciate that yours is not the only reasonable viewpoint.
There’s this, which doesn’t warn: $ perl -le 'if (do { goto foo }) { foo: }' But if you remove the ‘do{’ and ‘}’ surrounding the goto, it warns. What’s unfortunate about this is the timing. I never bothered arguing for keeping inward goto, because until a year ago the policy (even stated by a former pumpking) was that we would remove deprecated features when they got in the way of fixing bugs (e.g., do sub()), adding new features (<<), or just basic maintenance (use encoding, which was pervasive); otherwise the feature would be left alone. goto-LABEL fits into none of those categories, so I felt ‘safe’, as it were. The policy changed sharply a year ago, so I felt it was time to say something in defence of the construct. All this is a long-winded way of saying why I reject the reasoning, ‘it’s been deprecated long enough’. It’s hasn’t been ‘deprecated and in danger of being deleted’ long enough. -- Father Chrysostomos |
From @xsawyerxOn 11/24/2017 01:12 PM, Aaron Crane wrote:
Which brings us back to FC providing his use-case and seeing if there's |
From @cpansproutOn Tue, 28 Nov 2017 04:08:59 -0800, xsawyerx@gmail.com wrote:
All the cases above involve a pushmark, which is easy enough to check for. -- Father Chrysostomos |
From @davidnicolwith 5.10, the visibility or invisibility of labels is curious. Label $ perl -le 'goto X; map { print 22; X: print 55 } (1 .. 3)' On Tue, Nov 28, 2017 at 11:54 AM, Father Chrysostomos via RT <
-- |
From @cpansproutOn Wed, 29 Nov 2017 06:46:28 -0800, davidnicol@gmail.com wrote:
I see nothing curious in the output of those examples. (The examples themselves are another matter.) You can goto out of a subroutine, but you cannot goto into a subroutine, for an obvious reason: sub foo { BONK: } Which one wins? And how do you even find the label to begin with? The label has to be accessible via the context stack for sanity’s sake. -- Father Chrysostomos |
From @cpansproutOn Tue, 28 Nov 2017 09:54:46 -0800, sprout wrote:
And I’ve now forbidden the crashing cases in commit 6d90e98. -- Father Chrysostomos |
What to do about this ticket? |
There are well argued cases for and against, I think this is one for the PSC to make a decision on. |
PSC: can you put discussion of this ticket on your agenda? Thanks. |
I've added a note for next week's agenda |
Our question as of last week was: "Why not immediately?" |
@rjbs: Does that mean PSC has decided on removal? It would be worth stating that. :) It is not clear to me from reading the ticket that all forms of inward goto currently have a deprecation warning. For ones that warn, I think it might be acceptable to remove them immediately. If there are any that still don't warn it would be rude to make them immediate errors without a user-visible deprecation period. I don't know what the full list of distinguishable forms looks like, or I'd be able to check this for myself - @arc's examples already include cases I would not have thought of. |
Perl Steering Council: Can you respond to @hvds's concerns raised last year? Thank you very much. |
We've just discussed this in PSC. Thoughts are that things that currently already warn should immediately set a removal date of 5.42 so we can set a timeline. If there are other remaining cases that don't even warn, such warnings could be added but those cases would probably need the usual two-release-cycles of warning lifetime before they were removed. |
Works for me. I hope that the changes will turn out to be very close to the code that currently raises warnings - maybe even doing nothing but elevate those warnings to errors - so that it will be clear that only the warning paths are affected. |
Migrated from rt.perl.org#132492 (status was 'open')
Searchable as RT132492$
The text was updated successfully, but these errors were encountered: