First of all, we don’t have concepts for containers, only for ranges and iterators. For containers we have only named requirements. If you are asking why `operator[]` is not part of `random_access/bidirectional_range` then the answer is simple: because they are just ranges with `random_access/bidirectional_iterator`, nothing more, nothing less. Having `operator[]` for them doesn’t make much sense. For map and vector `operator[]` behaves differently, for map it doesn’t even exist for const `*this` which makes it pretty useless for any algorithm which is not supposed to modify the input sequence.
I guess that you need some generic `find_by(const Container&, T)` where T could be `size_type` for key-less sequences or `key_type` for ones with key. The first part obviously doesn’t need any new concepts, any range can satisfy it, the second part can be named like `findable/searchable_range` and require member `find(key_type)`.

On Sun, Oct 30, 2022 at 6:57 PM Phil Ratzloff via SG19 <> wrote:

operator[] makes coding much simpler and clearer when accessing elements in random_acess_ranges like vector and deque. It is also useful for the bidirectional_ranges like map and unordered_map. We could like to use operator[] in the graph algorithms and doing so would support writing more generic code, but the concepts for those ranges don’t require operator[].


Is there a reason operator[] isn’t a requirement for random_access_range? For bidirectional_range?


We would create a concept that would require operator[]. What caveats are there in doing that?


SG19 mailing list

Oleksandr Koval.