Oops, pressed send too fast: On 5.11.2025 23:38:58, Bob Weinand wrote:
Last thing - proper API usage forces you to use that construct.
I wanted to add that you have to use the construct to do it properly. But it's easy to either not be aware of with() and just see enterContext(), because that makes it work. Leaving the context is not strictly required for some use cases where you'd use the ContextManager.
Also, I have a lot of experience with it from C#, and it ... sucks. It's annoying. I forget about using() all the time. It's crappy design. It also only has IDisposable, and does not require enterContext() first. So yes, at least proper implementations of the ContextManager will probably do the effort to blow up in your face if you don't call enterContext(). But still, it's a discovery step away. It's not intuitive that it has to be called (or better, wrapped in with :-)) without running the code / looking at the actual interfaces implemented by the returned object.
The use() proposal has the big advantage, that function boundaries are pretty natural. You do not actually introduce cycles *that* easily, unless you store intermediary state (like callbacks, custom user objects). It will work flawlessly in most cases without use(). And it's easy to think "this is a database transaction, I probably should wrap it in use()" - without having any actual knowledge of the implementation details of the class (like the ContextManager being implemented).
Sure, use() is not *perfect* either - unlike e.g. Rust which intrinsically prevents cycles from being possible at all, but it's much better than the with() with all its shortcomings.
Small addendum on the forcing destructors topic: We might want to make the force-destructable behaviour opt-in. I.e. by default, if you use() an object and it leaves scope, nothing happens, unless a #[ForceDestructInUse] attribute is given, to prevent accidental destruction of objects which very much should not be autodestructed.
Sorry for splitting into two mails... Bob
