-
Notifications
You must be signed in to change notification settings - Fork 2.2k
Address #1138 when mixing holder_type's upon casting an object. #1139
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
base: master
Are you sure you want to change the base?
Conversation
bf3104e
to
acd86f0
Compare
Updated to pass tests, simplified override for |
The core issue in #1138 is that we don't check the holder type at all when initializing an instance: we just assume that a function returning a holder is returning the right kind of holder. I've just submitted #1161 to detect that and fail if it happens when attempting to register the type and/or function. There are some other cases this PR doesn't catch that the other one does: for example returning a More problematic, the change here would also break backwards-compatibility (and indeed breaks the current test suite) by requiring that any move-only holder adds a Conversion between holder types--e.g. being able to convert an rvalue |
Sweet! Will close this PR shortly. Will comment on the other PR. |
Philosophical question here: Can I ask what the actual intent is in delineating holder between copyable and move-only, rather than keeping it more towards shared and unique? |
It's not really a philosophical question, it's just that we have fundamentally different code paths when a holder can be copied, with the But more generally (and the thing that affects backwards compatibility) is that we allow |
This presently fails
test_move_only_holder
. Will inspect if there is a way around this - perhaps only killing the existing holder if there is no type match between holders?This addresses #1138.