[llvm-dev] RFC: Towards unified semantic for casts

[Dmitriy Borisenkov via llvm-dev]

Agreed, it probably shouldn't. Then we can use the detection idiom (e.g.
std::experimental::detected_or) with it in future. I updated the review.

--
Kind regards, Dmitry

On Tue, Jan 23, 2018 at 7:57 PM, David Blaikie <dblaikie at gmail.com> wrote:

> Looks pretty reasonable to me - with test cases. (not sure if
> dereferenced_type should be defined for a type that's not dereferenceable,
> though?)
>
> On Tue, Jan 23, 2018 at 7:02 AM Dmitriy Borisenkov via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi everyone,
>>
>> I have an idea that should allow reducing code duplication in Casting.h
>> while making llvm::isa, llvm::cast, llvm::dyn_cast, etc more generic. Since
>> we added unique pointers support for these template functions (see
>> ab480f45cd23c08cb9aa3f427aad072df249135f) I propose to generalize their
>> semantics to deal with any pointer-like type (i.e. dereferenceable and
>> implicitly convertible to bool) so that:
>>
>>    - for each fancy_pointer<T> t: isa<G>(t) returns true iff current
>>    implementation of isa<G>(nonfancy_t) returns true where
>>    decltype(nonfancy_t) is T*
>>    - all old cast operations should return a raw pointer of type
>>    typename std::pointer_traits<fancy_pointer<T>>::element_type * and do
>>    not perform ownership transfer.
>>    - move_[dyn_]cast should do what unique_dyn_cast is currently doing
>>    in a more generic manner: it moves to an object of type typename
>>    std::pointer_traits<fancy_pointer<T>>::rebind<G>
>>
>> N.B. std::pointer_traits is a conception that I use to explain the
>> behaviour - not necessary the way I plan to implement it.
>>
>>
>> An example implementation of the proposal for llvm::isa :
>> https://reviews.llvm.org/D42027
>>
>>
>> --
>>
>> Kind regards, Dmitry
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180123/734b515c/attachment.html>