On Fri, Mar 16, 2012 at 1:33 PM, Giovanni Piero Deretta <gpderetta@gmail.com
wrote:
On Fri, Mar 16, 2012 at 6:43 AM, Neil Groves <neil@grovescomputing.com wrote:
Boosters,
I am considering my position on this patch. I can see that it is
syntactic sugar, but the reason I consciously omitted this was that it suffers from combinatorial explosion. I feel that one of the nice aspects of the current Boost.Range design is that it reduces combinatorial explosion by breaking down items into their constituent orthogonal
On Fri, Mar 16, 2012 at 6:56 PM, Jeffrey Lee Hellrung, Jr. <jeffrey.hellrung@gmail.com> wrote: pleasant parts.
However I am reconsidering since there are a growing number of people requesting this feature, and perhaps the pragmatic convenience outweighs the slightly theoretical design concern. I need to make some effort to tackle some of the Boost.Range suggestions that have been accumulating during a period of ill health. I apologize for slow responses. It is important, to me, to make interface changes that I do not later regret. This needs some further investigation and thought.
My unrequested opinion: First, I understand the motivation. However, I think it would be inconsistent and confusing if some libraries in Boost treated pointers-to-member-functions specially while others did not. And I don't see all of Boost moving to specially support pointers-to-member-functions. Also, the workaround is seriously really not so bad (explicitly wrapping with mem_fn), especially given C++'s general penchant for verbosity.
Note that there is precedent in C++ for treating ptr-to-members and ptr-to-member functions specially, see for example the ConvertibleToFunction[1] concept employed by Adobe ASL library.
Also, boost::bind (and std::bind) do treat them specially, not requiring mem_fn.
Personally, I think it would be a great feature.
-- gpd
[1] http://stlab.adobe.com/group__concept__convertible__to__function.html
I don't have a strong opinion either way; I'm certainly sympathetic to the syntactic convenience on the client side! Referring to [1]: incidentally, I too had been using a function in my internal algorithms and data structures that allowed function objects, pointers-to-members(-functions), and (yes, even) boost::reference_wrappers of the aforementioned to all be treated uniformly, and I ultimately felt that the uglification of the algorithms/data structures was worse than the improvement at the use of the algorithm/data structure. Plus it took extra documentation to justify the rationale for wrapping all my calls that would otherwise look like "f(x)" with "invoke(f)(x)". - Jeff