It turns out it is useful to be able to define the deref type as void. In case we have a type erased owner, we want to express that the pointee can be basically any type. I think it should not be unnatural to have a void deref type as we already familiar with "pointers to void".
Details
Diff Detail
Event Timeline
Could you provide a more fleshed out example of a case where it is useful?
Could you update the documentation for the attribute? I'm forgetting if there's a spec for this attribute -- is this extension part of that spec?
Do you foresee any issues or further special cases? For example, IIRC, 'operator*' is required to return DerefType. I have a hard time understanding how one would define 'operator*' in such an owner.
Sure! The std::any could be one example (std::variant is similar, but ultimately, we migh want to be able to enumerate multiple types in that case rather than just using void).
The specific example I found was an allocator: https://fuchsia-review.googlesource.com/c/fuchsia/+/340159/3/zircon/kernel/lib/fbl/include/fbl/arena.h#25
This might not be super important as it might be unlikely that we will ever find a problem where an arena is destroyed before an object allocated there is dereferenced, but still, it is good to cover this use case as well.
Could you update the documentation for the attribute? I'm forgetting if there's a spec for this attribute -- is this extension part of that spec?
void is currently not mentioned in the documentation, but adding an example and the interpretation would help indeed, thanks!
Do you foresee any issues or further special cases? For example, IIRC, 'operator*' is required to return DerefType. I have a hard time understanding how one would define 'operator*' in such an owner.
I think those types that have void as deref types are unlikely to implement operator*. There might be some skeletons but I am not aware of anything at the moment.
clang/include/clang/Basic/AttrDocs.td | ||
---|---|---|
4619 | cna typo |
clang/include/clang/Basic/AttrDocs.td | ||
---|---|---|
4619 | Thanks! |
Sorry, just getting back to this review. Your justification makes sense, and the patch LGTM.
cna typo