<p>On 16/03/10 12:00, Filipe Cabecinhas wrote:</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p>Why replace “indexes.begin()”, which is pretty standard with “indexes_begin()”, which has more cognitive load with seemingly no gain?</p>
</blockquote>
<p>To make it have “symmetry” with <code>indexes_end()</code>.</p>
<p>The problem boils down to the previous code using the container in a rather weird way, and in order to not having to change all logic associated with the indexes (cues) prior to a (much likely) rewrite of everything that has to do with indexes, it was decided to simply wrap the old behavior.</p>
<p>As an example, when we first create the index container it will always contain one (<code>1</code>) index (due to legacy logic). That index is however not to be used when seeking, but only to act as a placeholder for code that needs to read/write some state depending on that index.</p>
<p>The previous code used the last element (ie. <code>container.end()-1</code>) as this placeholder, and this continues to be true after the rewrite. In order to not get confused by code such as:</p>
<pre><code>indexes_t::const_iterator cit = indexes.begin();

while (cit != indexes_end())
  ;</code></pre>
<p>Where one could think that using <code>indexes_end()</code> together with <code>indexes.begin()</code> is a mistake, it was decided to introduce <code>indexes_begin()</code> to make it really feel like they belong together.</p>
<p>However, one could have also changed the name of <code>indexes_end()</code> to something like <code>active_indexes_end()</code>, or something.. similar (naming is hard)–but that did not happen.</p>
<p>I would welcome a patch that clears up the naming of the two, though as said the entire segment will most likely be rewritten quite soon.</p>
<p>Thanks!</p>