id	summary	reporter	owner	description	type	status	milestone	component	version	severity	resolution	keywords	cc
10853	problem with detection of const_cast_from	Matei David <matei@…>	Ion Gaztañaga	"According to the documentation for the `boost::intrusive::pointer_traits` non-standard extensions, `pointer_traits<Ptr>::const_cast_from(const UPtr&)` should try to call `Ptr::const_cast_from(const UPtr&)` if it exists, or else use a default. It seems to me that this process fails with compilation error (not only misdetection) when `const_cast_from()` is a plain static function inside `Ptr`, as opposed to a function template. To trigger this process and the compilation error, use e.g. `front()` on an intrusive list.

For an example demonstrating this, look at `test/bounded_pointer.hpp` in the boost intrusive git repo. There, `const_cast_from` is a template:
{{{
template<class U> static bounded_pointer const_cast_from(const bounded_pointer<U> &)
}}}
For me (`gcc-4.9.2`, `clang-3.4`), the compilation fails if the signature is changed to:
{{{
static bounded_pointer const_cast_from(const bounded_pointer<const_val_t> &)
}}}
For a real program showing this, use the non-dummy version of `test/test_list.cpp`. (I don't understand why it was commented out.) To clarify, the problem has nothing to do with `bounded_pointer`, that's just an existing file demonstrating it.

Digging a bit into this issue, it appears that the problem is with the mechanism used to detect the presence `const_cast_from()` inside `Ptr`. That mechanism is in `boost/intrusive/detail/has_member_function_callable_with.hpp`. In my case, the error comes from line 200 of that file, saying that the call to `const_cast_from` is ambiguous: one candidate is the real function, the other candidate is the dummy declared on line 191. I believe the whole point is for overload resolution to prefer the real function to the dummy, which doesn't happen in this case."	Bugs	closed	To Be Determined	intrusive	Boost 1.57.0	Problem	fixed