On Sat, Jun 20, 2026 at 4:25 PM Bob Weinand <[email protected]> wrote: > I dislike this. > > Yes, it's a rare occurence. But it's used legitimately in most places you found. (as you say, only 3 places were genuine issues.) > > > So, why do you want to remove this? What's the point? It has some proper usage sites. > > We do have well-defined behaviour for return in finally. It works properly (by now) - it's not like it's a frequent source of bugs - there were a couple ones when initially introduced 10+ years ago, and a single one more recent. > > > Also, no, it's not inconsistent - goto, continue etc. break out of the finally block and continue the functions execution. A return stops function execution as well. These are two different considerations. > > > Feels a lot like "let's try changing something for the sake of it". No thanks. > > > Thanks, > Bob
Hi Bob, First, on framing, even though what I am suggesting here is removing it, I deliberately left the door open to a plain warning if people here preferred. The thing is that this is a silent footgun worth addressing... So I'll admit I didn't expect "leave it entirely" to be on the table for something that discards the in-flight state silently. On the "why" itself, it's not that the behavior is broken, it works exactly as defined. The problem is what it's defined to do, a return in finally silently discards a pending exception or return value, with no diagnostic at all. That *silence* is the whole case. And it's where the real damage is. The genuine cases I found are exactly that...a controller that swallows the very exceptions its own docblock declares it throws, a service that reports success after an I/O failure, and an HTTP driver that drops exceptions when a stream is gone. Nothing surfaces any of it, which is why they ship and stay shipped. So the benefit here is that we close a tiny gap that makes behavior less surprising and more predictable, and the cost of addressing that is close to nothing. It's in 0.18% of the top 5000 packages, and the deliberate uses don't even need it, the same behavior can be achieved in other ways (sometimes just one line away...the return just past the finally). So it removes no capability, it just makes the silent cases visible. On consistency, you're right...the jump bans are different. But that doesn't remove the concrete issue = the silent discard. That stays unchanged. Thanks, Osama
