-
Notifications
You must be signed in to change notification settings - Fork 0
iris::is_fancy_pointer<T> is needed #65
Copy link
Copy link
Open
Labels
enhancementNew feature or requestNew feature or requestlanguage-lawyerImplies unclear specification on the C++ standard, or potential misinterpretation/bug on compilersImplies unclear specification on the C++ standard, or potential misinterpretation/bug on compilers
Description
Activity
Metadata
Metadata
Assignees
Labels
enhancementNew feature or requestNew feature or requestlanguage-lawyerImplies unclear specification on the C++ standard, or potential misinterpretation/bug on compilersImplies unclear specification on the C++ standard, or potential misinterpretation/bug on compilers
For the implementation strategy, I'm not sure if there's some robust and standardized way to check fancy pointers.
We need to check the standard on the terminology "fancy pointer". I'm at least aware that we can't simply delegate to
std::pointer_traits<T>because there's some legit fallback that mistakenly enables its specialization, e.g. some classes likestd::spandefine::element_typeeven though they are not fancy pointers.The ad-hoc way (or maybe the only way if there exists no robust way) is to enable partial specialization for all variants below:
std::unique_ptr<T>std::shared_ptr<T>We are not confident how these should be treated:
std::weak_ptr<T>-- even though we can define this is a fancy pointer, the typical use case ofiris::is_fancy_pointer<T>is a pre-check for when you want to obtain the raw pointer of the given type unconditionally. That means, if we returntrueforstd::weak_ptr<T>, we are inevitably going to invokereturn ptr.lock().get();. I'm 100% sure that's misleading and semantically broken, because the reference can get destroyed in subtle timings.If we are going to reject
std::weak_ptr<T>, we might need to change our traits' name to likeiris::is_owning_fancy_ptr<T>. It really depends on how the C++ standard defines the term "fancy pointer" though.