feat: convenience accessor for query parameters

[alandefreitas]

Context

Currently, to get a parameter with a fallback, you must write:

auto p = u.params();
auto it = p.find("id");
if (it != p.end())
    use(*it);
else
    use("na");

Proposal

Add a shorthand:

u.params().get_or("id", "na"); // returns "na" if not found

Internal Discussion

11/07/2025

• Peter Dimov pointed out that value_or is a method name reserved for optional types (.value_or(def)).
• get_or aligns with the naming direction discussed in WG21 proposal P3091R4: get for associative containers and § “Other names for get”.
• Peter noted that in his own code this is typically called lookup() returning a pointer, but get_or is acceptable since it’s clear and consistent.
• The committee papers P3857R0 and P3091R4 show that the final naming direction for standard containers is still unsettled but likely to be get, so get_or matches the expected C++ naming evolution (get and get_or pairs).
• Avoids confusion with optional::value_or.

Next Steps

• Confirm naming (get_or)
• Implement in both params_encoded_view and params_view.

References:

• boost::urls::params_encoded_view
• P3091R4 — get for associative containers
• P3857R0 — get() for associative containers (follow-up)

[vinniefalco]

get_or is good and can we make the alternative a parameter that defaults to empty string?

[vinniefalco]

And can I also say this is a very nicely written issue

[alandefreitas]

we make the alternative a parameter that defaults to empty string?

Got it. So...

pct_string_view
get_or(
    pct_string_view key,
    pct_string_view value = {},
    ignore_case_param ic = {}) const noexcept;

like https://www.boost.org/doc/libs/latest/doc/antora/url/reference/boost/urls/params_encoded_base/find-0c.html