NewKernel_d: Get_functior<Kernel, Tag, O, T>

[lrineau]

@mglisse In NewKernel_d, I see

cgal/NewKernel_d/include/CGAL/NewKernel_d/functor_tags.h

Lines 32 to 33 in 0175389

	template <class K, class F, class O=void, class=void> struct Get_functor
	: K::template Functor<F, O> {};

I imagine that the third template parameter, O, is an "option", that could be for example No_lazyness, if we want a construction from Epeck that does not create a graph of construction.

What was your plans for the fourth parameter? I have seen that code:

cgal/NewKernel_d/include/CGAL/NewKernel_d/utils.h

Lines 146 to 157 in 0175389

	#define CGAL_KD_DEFAULT_FUNCTOR(Tg,Name,ReqTyp,ReqFun) \
	template <class K, class O> \
	struct Get_functor<K, Tg, O, \
	typename boost::mpl::if_c< \
	Provides_functor_i<K, Tg, O>::value \
	|| !Provides_types<K, boost::mpl::vector<CGAL_STRIP_PAREN_ ReqTyp> >::value \
	|| !Provides_functors<K, boost::mpl::vector<CGAL_STRIP_PAREN_ ReqFun> >::value \
	, int, void>::type> \
	{ \
	typedef CGAL_STRIP_PAREN_ Name type; \
	typedef K Bound_kernel; \
	}

and it seems to be using that fourth parameter (with value int or void). But I do not see where specializations with int are used.

As said in #5892 (comment), I would like to review that API Get_functor, and then consider adopting it for Kernel_23 as well.

[mglisse]

The fourth parameter is only there to help with dispatching / overloading / specializing. IIRC, only the void version is used, but it can be convenient as an implementation detail, when I don't want to provide the specialization, I provide it but with a wrong last parameter (int).

I don't think I ever really used the "option" part of Get_functor, so I cannot promise how well it would work. For instance, I don't seem to forward the option consistently, Cartesian_wrap already drops it, so it wouldn't reach Lazy_cartesian, although that would probably not be too hard to fix.