On Tue, Aug 24, 2021 at 6:01 PM Robert Ramey via Boost < boost@lists.boost.org> wrote:
I guess if it doesn't work, it's not valid. Certainly from what little user documentation there is - cpp reference, there's no information on this topic. My user case looks like:
template<typename T> struct interval { T m_min; T m_ max; interval(const T & min, const T & max) : m_min(min), m_max(max) {} }
template<typename T> constexpr interval<T> get_interval(const T & t) { return std::is_constant_evaluated() ? interval<T>(t, t); // we know the value of t at compile time so the range is effectively [t, t] : interval<T>(std::numeric_limits<T>::min(), std::numeric_limits<T>::min()); // otherwise we won't know the value until runtime so it could be in the range [...] ; }
So I'm returning different values depending on whether we're compiling or execution. In fact, if we know the value of t at compile time, the runtime code will never be executed. So there would never be an ambiguity, but of course the compiler can't see that so maybe that's why the compiler is unhappy with this.
Still not 100% clear what bigger goal is, for me example code compiles https://www.godbolt.org/z/sbKGh53ec when I make constructor constexpr. I presume you want to use the returned interval to construct some types(for example something like safe_signed_range ) and that is where the problems may occur. As far as I know this is impossible in C++, to have constexpr arguments, unless you use them as template arguments, e.g. func<3>(), but if you have func(3) there is no way to get that 3 during compile time. So even if this new boost macro is added that will not help you since even if compiler knows that 3 is 3 it will not let you to use it at compile time due to C++ language rules https://www.godbolt.org/z/hWPTGvPss. So I am not an expert, but I think it is indeed not possible to do what you want.