Re: [boost] [Fit] Review

Subject: Re: [boost] [Fit] Review
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2016-03-11 02:01:55

Le 11/03/2016 07:18, Edward Diener a écrit :
> On 3/11/2016 12:10 AM, Paul Fultz II wrote:
>>
>>
>>>>
>>>> We can define functions by simply composing other functions 
>>>> together and
>>> we
>>>> don't need to write awkward syntax nor template boilerplate for it. 
>>>> For
>>>> example, we can simply write `make_tuple` like this:
>>>>
>>>>       BOOST_FIT_STATIC_FUNCTION(make_tuple) = by(decay,
>>>> construct<std::tuple>());
>>>
>>> What is the type of by(decay,construct<std::tuple>()) ?
>>>
>>
>> It is something like `by_adaptor<decltype(decay), 
>> construct<std::tuple>>`.
>>
>>
>>> I thought I would be able to write locally:
>>>
>>> auto make_tuple(by(decay,construct<std::tuple>()));
>>>
>>> but evidently you are saying that does not work.
>>>
>>
>> That is not what I am saying at all. It can work, the functions can 
>> be used
>> locally, like in the first example. However, for `make_tuple` this is 
>> not
>> useful at all. If `std::make_tuple` was assigned to a local variable 
>> then no
>> one could ever call the function.
>
> I don't understand this. I have a 'make_tuple' callable above and if I 
> want to use it somewhere else I pass it to whatever functionality 
> needs it. You, instead want things to be global so that they can be 
> used by other functionality without passing anything around. Isn't 
> this just an argument about programming style ? I don't mind if you 
> like your programming style but I doubt I am the first or last 
> programmer who prefers variables created and used when needed. In fact 
> I have a very strong suspicion that "my" programming style is that of 
> the majority of C++ programmers and that only a minority of 
> programmers like global variables even if they can be global within a 
> namespace scope. So what I am essentially saying is that while I 
> understand you like your style and your macros for creating "global" 
> callables, inferring that this is central to using your library, when 
> it is not AFAICS, is going to lose you end-users as well as 
> misrepresent your library. I see much more plusses to your library if 
> the result of using your adapters, decorators, functions, and 
> utilities can be instantiated anywhere and used in ways that any 
> variable in C++ can be used. if however there are real technical 
> limitations, as opposed to "I like this style because I it is easier 
> for me to use with Fit", of using Fit functionality to create "local" 
> objects I think you need to spell out what those limitations are.
Eduard, I don't know if you are aware of the Eric's paper [1] about 
customization points. In this papers Eric presents the technique use by 
Fit to define global function objects. These global variables have no 
modifiable state and are just like functions, but are high order 
functions. Eric received a very good feedback from C++ committee and 
AFAIK the range-v3 library [2] and the Range TS [3] are based on this 
technique.

I believe that it will be better if Paul show what is behind those 
macros by writing what the user could do without. E.g. the static_const 
ODR helper lets the user just write

|constexpr auto const & begin = boost::static_const<__detail::__begin_fn>;|

Paul goes one step far, by defining some macros that help to do that.

Best,
Vicente

[1] N4381 - Suggested Design for Customization Points
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4381.html
[2] https://github.com/ericniebler/range-v3
[3] N4569 - Proposed Ranges TS working draft
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/n4569.pdf