result_of deprecation from c++20 workaround (PR #3846)

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

result_of deprecation from c++20 workaround (PR #3846)

Ahmed Essam
Hi all,

I'm Ahmed Essam, and I'm interested in applying for GSoC with you this year.

Regarding PR #3846. As I understand it, the main blocker is the deprecation of `std::result_of` from C++20 in favor of `std::invoke_result`. I think there is a workaround that would work with both C++11 and C++20 when the removal happens. The main idea comes from this blogpost https://devblogs.microsoft.com/oldnewthing/20190710-00/?p=102678.
We will use SFINAE to choose `std::invoke_of` if available, otherwise, choose `std::result_of`. I'm not sure is the mapping of the functionalities here covers all cases, but I think it's worth trying. Please find the code snippet below:


If you think this might work, I can make a PR for it.

Thanks,
Ahmed Essam
Reply | Threaded
Open this post in threaded view
|

Re: result_of deprecation from c++20 workaround (PR #3846)

Marc Glisse
On Fri, 28 Feb 2020, Ahmed Essam wrote:

> Hi all,
>
> I'm Ahmed Essam, and I'm interested in applying for GSoC with you this year.
>
> Regarding PR #3846 <https://github.com/CGAL/cgal/pull/3846>. As I
> understand it, the main blocker is the deprecation of `std::result_of` from
> C++20 in favor of `std::invoke_result`. I think there is a workaround that
> would work with both C++11 and C++20 when the removal happens. The main
> idea comes from this blogpost
> https://devblogs.microsoft.com/oldnewthing/20190710-00/?p=102678.
> We will use SFINAE to choose `std::invoke_of` if available, otherwise,
> choose `std::result_of`. I'm not sure is the mapping of the functionalities
> here covers all cases, but I think it's worth trying. Please find the code
> snippet below:
>
> https://gist.github.com/theartful/3dd554239743b4489b2356058f12a432
>
> If you think this might work, I can make a PR for it.

The PR you mention mostly solves the issue by using neither result_of nor
invoke_result. CGAL only started using result_of because decltype(auto)
didn't exist at the time.

I don't think sfinae code to detect result_of/invoke_of would help much,
we can use __cpp_lib_is_invocable. But we should first remove most uses of
result_of, and only then see if it makes sense to keep the few remaining
ones as is, with a version of result_of that forwards to invoke_result, or
if using decltype or some other constructs to remove result_of would be
better.

(of course this is just my opinion, others may see things differently)

--
Marc Glisse

--
You are currently subscribed to cgal-discuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgal-discuss


Reply | Threaded
Open this post in threaded view
|

Re: result_of deprecation from c++20 workaround (PR #3846)

Ahmed Essam
Thanks for the reply.

I was reading through the mailing list and found this by the author of the PR on Feb 26

> To get started you can try to fix that PR:
> https://github.com/CGAL/cgal/pull/4238
>
> And then that one where the goal was to remove the usage
> of the old boost::tr1::result_of and replace it by std::result_of:
> https://github.com/CGAL/cgal/pull/3846
>
> You'll get bonus points if you find a solution to handle the
> depreciation of std::result_of in c++20.
>
> Best,
>
> Sebastien.

If backward compatibility is the case, this solution should work with c++11 and c++20.
But indeed I agree. It would be better all of `result_of` are replaced by `delctype(auto)`. It's simpler and cleaner.

Thanks,
Ahmed Essam.

On Fri, Feb 28, 2020 at 8:56 PM Marc Glisse <[hidden email]> wrote:
On Fri, 28 Feb 2020, Ahmed Essam wrote:

> Hi all,
>
> I'm Ahmed Essam, and I'm interested in applying for GSoC with you this year.
>
> Regarding PR #3846 <https://github.com/CGAL/cgal/pull/3846>. As I
> understand it, the main blocker is the deprecation of `std::result_of` from
> C++20 in favor of `std::invoke_result`. I think there is a workaround that
> would work with both C++11 and C++20 when the removal happens. The main
> idea comes from this blogpost
> https://devblogs.microsoft.com/oldnewthing/20190710-00/?p=102678.
> We will use SFINAE to choose `std::invoke_of` if available, otherwise,
> choose `std::result_of`. I'm not sure is the mapping of the functionalities
> here covers all cases, but I think it's worth trying. Please find the code
> snippet below:
>
> https://gist.github.com/theartful/3dd554239743b4489b2356058f12a432
>
> If you think this might work, I can make a PR for it.

The PR you mention mostly solves the issue by using neither result_of nor
invoke_result. CGAL only started using result_of because decltype(auto)
didn't exist at the time.

I don't think sfinae code to detect result_of/invoke_of would help much,
we can use __cpp_lib_is_invocable. But we should first remove most uses of
result_of, and only then see if it makes sense to keep the few remaining
ones as is, with a version of result_of that forwards to invoke_result, or
if using decltype or some other constructs to remove result_of would be
better.

(of course this is just my opinion, others may see things differently)

--
Marc Glisse

--
You are currently subscribed to cgal-discuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgal-discuss