In the aggregated reference page for boost::urls::param_view constructors, equivalent parameters are named differently across overloads. When all overloads are shown together, the inconsistent naming makes the API harder to read and suggests semantic differences that don’t actually exist.
Reference:
https://www.boost.org/doc/libs/master/doc/antora/url/reference/boost/urls/param_view/2constructor-0e.html
Examples include:
key vs key_value vs value_has_value vs has_value_
Each overload makes sense on its own, but the differences become distracting when aggregated. We should normalize parameter names across overloads.
In the aggregated reference page for
boost::urls::param_viewconstructors, equivalent parameters are named differently across overloads. When all overloads are shown together, the inconsistent naming makes the API harder to read and suggests semantic differences that don’t actually exist.Reference:
https://www.boost.org/doc/libs/master/doc/antora/url/reference/boost/urls/param_view/2constructor-0e.html
Examples include:
keyvskey_valuevsvalue_has_valuevshas_value_Each overload makes sense on its own, but the differences become distracting when aggregated. We should normalize parameter names across overloads.