Some container member functions require iterators of type "iterator";
iterators of type "const_iterator" won't do.  An example of such a function
is single-element erase:

  ReturnType ContainerType::erase(iterator);  // parameter type is
                                              // iterator;
                                              // const_iterator won't do

I'm trying to figure out why the type "iterator" has such an exalted
status.

The proposed resolution to LWG Issue 180 was to "change all non-const
iterator parameters of standard library container member functions to
accept const_iterator parameters," but this was rejected, and this is
included in the rationale:

  The LWG believes that this issue should be considered as part of a
  general review of const issues for the next revision of the standard.
  Also see issue 200.

A comment for LWG Issue 200 reads:

  The LWG believes this is the tip of a larger iceberg; there are multiple
  const problems with the STL portion of the library and that these should
  be addressed as a single package.  Note that issue 180 has already been
  declared NAD Future for that very reason.

As I said, my interest is in determing why some functions insist on
parameters of type "iterator".  The above comments suggest to me that if
they had it to do over again, the members of the Committee might not make
the same decision.  I'd appreciate it if people with personal knowledge of
the history of this decision could clarify how things got to be the way
they are.  I'm writing an article for CUJ, and I've been asked to address
this specific question in the article.  I'd prefer not to have to guess...

Thanks,

Scott

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Scott Meyers <smeyers@aristeia.com> writes:

> As I said, my interest is in determing why some functions insist on
> parameters of type "iterator".  The above comments suggest to me
> that if they had it to do over again, the members of the Committee
> might not make the same decision.

[I can't answer your question, but would like to add to it.]

If the function is only using the iterator to point a location and
won't be modifying the pointed-to value, why can't these functions
accept

  const iterator&

or, to include Scott's proposal,

  const const_iterator&

Doesn't the "const-ness" of const_iterator only surround ones ability
to modify the value through iterator?

--
Steven E. Harris        :: steven.harris@tenzing.com
Tenzing                 :: http://www.tenzing.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Scott Meyers <smeyers@aristeia.com> writes:

> Some container member functions require iterators of type "iterator";
> iterators of type "const_iterator" won't do.  An example of such a function
> is single-element erase:
>
>   ReturnType ContainerType::erase(iterator);  // parameter type is
>                                               // iterator;
>                                               // const_iterator won't do
>
> I'm trying to figure out why the type "iterator" has such an exalted
> status.

No good reason.  As far as I know, changing the parameter type to
"const_iterator" would work perfectly well.  It would not cause any
problems with const correctness, and, while there are one or two
places where it would make life slightly harder for implementors, it
would not make life harder for users.

> The proposed resolution to LWG Issue 180 was to "change all non-const
> iterator parameters of standard library container member functions to
> accept const_iterator parameters," but this was rejected, and this is
> included in the rationale:
>
>   The LWG believes that this issue should be considered as part of a
>   general review of const issues for the next revision of the standard.
>   Also see issue 200.

There weren't any technical arguments against making this change.  I
believe the LWG was unanimous that the change would be an improvement.

The LWG chose not to make this change because we didn't think we could
justify it as fixing a "defect".  The standard is what it is.  We're
not working on a new standard right now, we're just making bug fixes:
fixing omissions, contradictions, and so on.  The line between a bug
fix and a new feature is subjective, of course, but most of the LWG
thought that this would be the latter, not the former.

> I'd appreciate it if people with personal knowledge of
> the history of this decision could clarify how things got to be the way
> they are.

Because nobody thought of it in time.  These functions took a
parameter of type "iterator" in the original HP proposal, and nobody
noticed, until very shortly before the FDIS went out, that it would be
useful and safe to change it to "const_iterator".  I'm afraid there's
nothing more to it than that.  There never was a deliberate decision
that it would be better for the parameters to be "iterator" than for
them to be "const_iterator".

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]