Re: [Boost-bugs] [Boost C++ Libraries] #7630: Range adaptors do not play nicely with range-based for loops

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #7630: Range adaptors do not play nicely with range-based for loops
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2014-02-01 06:09:26

#7630: Range adaptors do not play nicely with range-based for loops
-------------------------------+------------------------
  Reporter:  gromer@…          |      Owner:  neilgroves
      Type:  Bugs              |     Status:  new
 Milestone:  To Be Determined  |  Component:  range
   Version:  Boost 1.51.0      |   Severity:  Problem
Resolution:                    |   Keywords:  range
-------------------------------+------------------------

Comment (by nathanridge):

 I reviewed this patch over email (shortly after it was posted) and made
 some (minor) suggestions. I'm posting them here now so that if someone
 would like to pick up the work on this bug, they are able to:

  - In the constructor of the primary template of extend_temporary,
    we know that the constructor argument will be an rvalue, right?
    So, would it make sense to use std::move instead of std::forward?

  - Given that the primary template of extend_temporary will never
    be used in C++98 mode (i.e., with no rvalue references), why
    even define it?

  - Regarding the change to range_iterator to have it accept
    a reference to a range as an input type:

        I think has_range_iterator should be updated correspondingly
        (notice how it uses range_mutable_iterator and
        range_const_iterator directly right now).

        While most range metafunctions go through range_iterator, and
        will therefore also start working on references to ranges,
        there is a partial specialization of range_size in
        boost/range/size_type.hpp that will break if its argument
        is a reference to a range. I think that should be updated too
        for consistency.

        Since these changes can stand on their own, I think they make
        sense as an independent patch. In fact, such a patch would
        resolve https://svn.boost.org/trac/boost/ticket/7885 .

  - Regarding the choice of range adaptor return type: I understand
    that

         adaptor<Range&> for lvalue ranges and

         adaptor<Range>  for rvalue ranges

    is what falls naturally out of template argument deduction.
    However, would something that makes the lvalue/rvalueness of
    the wrapped ranges more explicit be more readable? For example,

         adaptor<Range&>  for lvalue ranges and

         adaptor<Range&&> for rvalue ranges

    or

         adaptor<Range, lvalue_tag> for lvalue ranges and

         adaptor<Range, rvalue_tag> for rvalue ranges?

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/7630#comment:11>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.