It is often useful to look for a sentence that introduced an element, since there is often an accompanying rationale. In this case, N1443 says the following:
G. Bucket Interface
Like all standard containers, each hashed container has a member function begin () and end (). The range [c.begin (), c.end ()) contains all the elements in the container presented as a flat range. The elements inside the bucket are adjacent, but the iterator interface does not contain information about where one bucket ends and the next begins.
It is also useful to expose the bucket structure for two reasons. Firstly, it allows users to examine how well their hash function performs: it allows them to check how even elements are distributed inside the bucket, and look at the elements inside the bucket to see they have common properties. Secondly, if iterators have a basic segmented structure (as in existing singly linked lists), algorithms that use this structure with an explicit nested loop may be more efficient than algorithms that treat elements as a flat range.
The most important part of the bucket interface is overloading begin () and end (). If n is an integer, [begin (n), end (n)) is a range of iterators pointing to elements in the nth bucket. These members of the function return iterators, of course, but not of type X :: iterator or X :: const_iterator. Instead, they return iterators such as X :: local_iterator or X :: const_local_iterator. A local iterator is capable of iterating in a bucket, but not necessarily between buckets; some implementations allow X :: local_iterator to be a simpler data structure than X :: iterator. X :: iterator and X :: local_iterator are allowed to the same type; implementations that use bidirectional lists are probably freedom.
This bucket interface is not provided by SGI, Dinkumware, or Metrowerks Implementation. This is partly inspired by the Metrowerks collision detection interface, and partly by the early work (see [Austern 1998]) on algorithms for segmented containers.