On Mon, 16 Sept 2024 at 12:57, Peter Dimov via Boost
What sort of changes are you anticipating? Opting out of std::format range formatting was one thing we discovered. Does boost jason have similar
Steve Downey wrote: things
for ranges?
Everything that does automatic range handling will potentially be affected, e.g. hash_value.
Yes, Boost.JSON does this as well (provide a default implementation for range- like things.)
This is an extremely important point. This change will break real-world code. I have many cases where I have an overload that is differentiated by using the std::xxx_range concept. If I understand correctly, having optional model range will potentially alter overload resolution. This most likely will lead to compilation errors, but it seems entirely possible to have silent runtime errors, making the change unforgivable, in my opinion. The evidence, already, is that library maintainers are having to check to see if this will break their code. This to me, demonstrates that there is acceptance by many others that this has the potential to break existing code. The design alternative to have a non-member function adapter seems safer, more extensible and more re-usable. I very rarely want an optional to behave like a range. I find it hard to imagine this is the typical semantic most use-cases have in mind for optional. Making "optional" model any of the xxx_range concepts directly is an extremely bad idea because it will break code for very little upside compared to having an explicit call to adapt. Regards, Neil Groves