David Abrahams writes:
Aleksey Gurtovoy <agurtovoy@meta-comm.com> 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