return a list of values for query parameters with the same key about url

[vinniefalco]

This would be a nice example

[vinniefalco]

If we do this in the library it would be something like

subrange params_encoded_view::find_all( string_view key );

[vinniefalco]

It would be nice to have an API that make possible to return all values associated with a key in a list/container

I don't think the library should provide this explicitly. Instead, with the proposed find_all above, you could use std::back_insert_iterator (C++11) or one of the new fancy range algorithms to fill in the container of your choosing, even supporting custom allocators.

[vinniefalco]

boost.http.proto supports this:
https://github.com/CPPAlliance/http_proto/blob/dc92ac4e05ad8b1b4b60ec8924b2f0cfa1167598/include/boost/http_proto/fields_view.hpp#L243

[alandefreitas]

Cons:

1. It would be like emulating map::equal_range to a container where equal keys are not in order. We also have unordered_map::equal_range but the equal keys are also in sequence in these containers.
2. To emulate something that's not there, we would need a view that would be a lot like ranges::views::filter and pretend this is native. This would need a reasonable API, etc... which could involve a lot of work to get right.
3. There are many possible designs for the API, like a std::back_insert_iterator. Each design would serve only a subset of users.
4. Doing that implicitly might indicate to the user this happens in constant time, like some kind of weird vector::push_front would.
5. This is useful for avoiding a for-loop. But seems like a lot of work for just avoiding a for-loop. Users would need to understand the design.

Pros:

On the other hand, params::find does the same thing, assuming linear time is justifiable for URLs. Since params::find_all would also be linear time, it's not something completely without a precedent.

However, params::find has a much simpler interface, since we just return one iterator that already exists, so the precedent is not completely there.

[vinniefalco]

we can just wait until a user requests it.