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 <
sg19_at_[hidden]> 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
> SG19_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg19
>

-- 
Regards,
Oleksandr Koval.