[PATCH] D36049: [Resubmitted] Remove uses of deprecated std::unary_function, binary_function, and pointer_to_unary_function.

David Blaikie via llvm-commits llvm-commits at lists.llvm.org
Thu Aug 3 11:36:35 PDT 2017


On Thu, Aug 3, 2017 at 11:23 AM Justin Bogner via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> David Blaikie via Phabricator <reviews at reviews.llvm.org> writes:
> > dblaikie added inline comments.
> >
> > ================
> > Comment at: include/llvm/ADT/STLExtras.h:61-62
> > +struct identity {
> > +  using argument_type = Ty;
> > +  using result_type = Ty;
> > +
> > ----------------
> > Should these changes be adding all these typedefs? I assume the reason
> > std::unary_function et. al. are deprecated is that callers should
> > likely be using decltype & similar things to work here instead?
>
> IIUC the intent of deprecating these wasn't to get rid of the typedefs,
> but instead to discourage things from saying they operate specifically
> on a unary_function. Ie, it's better if some algorithm depends (in a
> SFINAE way) on the type defining an argument_type and result_type rather
> than on the type being isa-unary_function.
>

Got a reference? That would seem somewhat surprising to me.

All the things in the standard library that used to derive from
std::binary_function, etc, no longer do so and do not provide the typedefs.
So any adapter we have that depends on the typedef is not going to work
with the standard ones (std::plus<T> - to take a simple example) - nor any
others likely to be written in the future. The typedefs as a means to
interoperate with functors seems to have been removed/deprecated - so it
doesn't look to me like removing the type but keeping the typedefs achieves
so much of the point the standard was making of removing the types.

_______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170803/812a4ee3/attachment.html>


More information about the llvm-commits mailing list