CGAL users discussion list

[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 <> 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