<div dir="ltr">This was authored to address CMake build failure in Visual C++ 2017 with /std:c++latest.<br></div><div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br>
<table style="border-top:1px solid #d3d4de">
        <tr>
        <td style="width:55px;padding-top:13px"><a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon" target="_blank"><img src="https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif" alt="" width="46" height="29" style="width: 46px; height: 29px;"></a></td>
                <td style="width:470px;padding-top:12px;color:#41424e;font-size:13px;font-family:Arial,Helvetica,sans-serif;line-height:18px">Virus-free. <a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link" target="_blank" style="color:#4453ea">www.avast.com</a>
                </td>
        </tr>
</table><a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1" height="1"></a></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 8, 2017 at 4:39 PM, Justin Bogner <span dir="ltr"><<a href="mailto:mail@justinbogner.com" target="_blank">mail@justinbogner.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> writes:<br>
> On Thu, Aug 3, 2017 at 11:23 AM Justin Bogner via llvm-commits <<br>
> <a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a>> wrote:<br>
><br>
>> David Blaikie via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> writes:<br>
>> > dblaikie added inline comments.<br>
>> ><br>
>> > ================<br>
>> > Comment at: include/llvm/ADT/STLExtras.h:<wbr>61-62<br>
>> > +struct identity {<br>
>> > +  using argument_type = Ty;<br>
>> > +  using result_type = Ty;<br>
>> > +<br>
>> > ----------------<br>
>> > Should these changes be adding all these typedefs? I assume the reason<br>
>> > std::unary_function et. al. are deprecated is that callers should<br>
>> > likely be using decltype & similar things to work here instead?<br>
>><br>
>> IIUC the intent of deprecating these wasn't to get rid of the typedefs,<br>
>> but instead to discourage things from saying they operate specifically<br>
>> on a unary_function. Ie, it's better if some algorithm depends (in a<br>
>> SFINAE way) on the type defining an argument_type and result_type rather<br>
>> than on the type being isa-unary_function.<br>
>><br>
><br>
> Got a reference? That would seem somewhat surprising to me.<br>
<br>
</span>I can't seem to find where I got this from. Maybe I misremembered or<br>
made it up.<br>
<span class=""><br>
> All the things in the standard library that used to derive from<br>
> std::binary_function, etc, no longer do so and do not provide the typedefs.<br>
> So any adapter we have that depends on the typedef is not going to work<br>
> with the standard ones (std::plus<T> - to take a simple example) - nor any<br>
> others likely to be written in the future. The typedefs as a means to<br>
> interoperate with functors seems to have been removed/deprecated - so it<br>
> doesn't look to me like removing the type but keeping the typedefs achieves<br>
> so much of the point the standard was making of removing the types.<br>
<br>
</span>Interestingly, while std::unary_function and friends were deprecated in<br>
C++11, the typedefs were not deprecated then. It's only C++17 that<br>
deprecates the typedefs (and also removes the function binder classes).<br>
So uses that depend on the typedefs will certainly work in any standard<br>
up to and including C++17 (even for std::plus), but not necessarily in<br>
future standards.<br>
<br>
TLDR, I agree that it looks like they're removing the typedefs<br>
completely going forward, and it makes sense for us to follow suit.<br>
</blockquote></div><br></div>