[boost] Re: Iterator adaptors <-> boost::bind interaction

From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2005-06-10 02:40:47

David Abrahams writes:
> Aleksey Gurtovoy <agurtovoy_at_[hidden]> writes:
>> Yes, it's in the 'make_transform_iterator's current semantics. I
>> should have phrased the above as
>>
>>      I would say 'make_transform_iterator' should by default return a
>>      'transform_iterator' which 'operator*' always returns by value
>>      and there should be an explicit notation to request by reference
>>      semantics (if it's compatible with the transformation function's
>>      return type).
>
> Okay, so the next question.   Do we
>
>   a. Pick a new name for this make_transform_iterator to avoid
>      breaking existing uses
>
>   b. Change the semantics to un-break older uses (and
>      if so, what do we call the current semantics?)
>
>   c. Something else?

I'm strongly in favor of (b); in case I didn't make myself clear in
http://article.gmane.org/gmane.comp.lib.boost.devel/124639, though, I
maintain that relying on the specific transformation function's
signature to get a particular dereference behavior that happens to
work now -- that is, the current semantics, -- in majority of cases
simply puts in a maintenance time bomb. Furthermore, I might be
missing something, but I don't see a single compelling use case for
this behavior except that "we can do that". You know when you want
your iterator's 'operator*' to return by reference, and once you've
established that, you want the compiler to enforce it for you. So, my
proposal would be:

1) Revert 'make_transform_iterator' to pre-1.32 semantics (return by
   value).

2) Introduce 'make_reference_transform_iterator' which would
   explicitly ask for return by reference and enforce the
   corresponding signature of the transformation function.

3) Leave 'transform_iterator' intact, allowing for unforeseen use
   cases which would benefit from its current default behavior.

-- 
Aleksey Gurtovoy
MetaCommunications Engineering