вс, 15 сент. 2024 г. в 20:55, Andrzej Krzemienski via Boost
2. Given that we have standard concepts that detect the range interface, `std::ranges::range` it is reasonable to assume that programmers use it in their code, also for controlling the overload resolution. Suddenly adding the range interface to optional is likely to break their code. (While any change whatsoever could theoretically break code, the current problem is more likely, because we are talking about the standardized concept.)
I am now realizing that this is in fact what will happen with Boost.JSON's support for optionals. Luckily, the fix is trivial. Although it will lead to a behaviour difference observable by users, so may in turn lead to breakages (though, that's not very likely). I guess, I should make that change before standard libraries start shipping Range interface for std::optional.