On Wed, Apr 22, 2026, at 1:28 PM, Larry Garfield wrote:
> ## Conclusion > > I think a key question to answer here is: Do we care to differentiate > between CM errors and underlying errors? If not being able to do so is > a non-issue, or small enough that we don't care, then we have more > options. I'm not sure which of the last 3 I like most/dislike least: > "always rethrow", "call method to suppress", "throw special to > suppress". They all have pros and cons. > > If we do care, then we may need to adapt the materialized code and > expand the syntax in some way to allow for it. I'm not sure yet what > that would look like. > > I will stop here, however, and ask for input from the audience. (Not > just the regulars in this thread of late, but all of you reading this.) > Including if you have an alternate approach to the three listed above > that would have notably fewer cons. > > --Larry Garfield Coming back here with another option. Inspired by Bob's earlier message, I spent a little time noodling with going all in on generator-based context managers, aka "single-function" CMs. My noodling is here: https://gist.github.com/Crell/a599423f9e7c312650a45b0bcbafa473 It shows a few of the examples from the RFC converted to single-function generators with attribute tags. I also imagined what it would look like if we were to special case an object with __invoke() and an attribute tag, so that it could be autoloaded. And that in turn suggested going back to an interface but with a single method that must be a generator. All of those are shown in the gist. I think there is potential here. I list some of the pros/cons at the bottom. The big win is that it largely resolves the return-value/suppression question; the CM author is writing their own try-catch-finally anyway, so they can make it work however the heck the want it to using existing syntax. The downside is largely that it opens up some other questions about other parts of generators and what they do; Arnaud pointed out that simply forbidding those (returning from the CM generator or yielding with a key) until we decide what they should do is a viable option, and if the consensus is to do that I'd be OK with it. We haven't tried implementing any of the above yet; we want to get feedback on how folks feel about it as an alternative to the two-method approach. Please share your thoughts. --Larry Garfield
