labath added a comment. This isn't a feature I would want advertise too broadly, or add special APIs to support it. The way I see it, if a user needs to check if an object has been cleared, something has gone wrong already. So I'd rather do something to discourage this use case instead of providing more support for it. Crashing is definitely discouraging, but maybe a bit too extreme. If there was a simple way to throw an exception in this case, then I think that would be a good compromise.
The reason I started looking into all of this is because of a bug report where the user wanted to stash a debugger object and access it later (which is a semi-reasonable thing to do, I'd say). I haven't heard of anybody trying to store SBCommandReturnObjects, nor I intend to start encouraging that. The only reason I wrote this patch is to tie up loose ends. > Having the object reseted by SWIG if it goes out-of-scope could collide with > this approach. What do you think ? I'm not sure what you meant by that, but I don't consider this behavior as set in stone. If we come up with a different/better way to handle this, then we can just change this code. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D116162/new/ https://reviews.llvm.org/D116162 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
