Re: [boost] [Fit] Review

Subject: Re: [boost] [Fit] Review
From: Paul Fultz II (pfultz2_at_[hidden])
Date: 2016-03-11 02:48:02

On Friday, March 11, 2016 at 1:02:15 AM UTC-6, Vicente J. Botet Escriba 
wrote:
>
> 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 
>

I think I should add a section on "Declaring functions" that discusses this.
In the Quick Start guide or introduction, it would be better to describe it 
as
a declaring a function(which can refer to the "Declaring functions" section)
instead of using the term global variable as it can be interpreted
differently.
 

>
> |constexpr auto const & begin = 
> boost::static_const<__detail::__begin_fn>;| 
>
> Paul goes one step far, by defining some macros that help to do that. 
>

This is to help portability and initialization for all platforms.
 

>
> 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 
>
>
> _______________________________________________ 
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost 
>