Re: [fusion] Proposal for deprecating fusion.tuple.

On Sat, 30 Sep 2017 10:23:22 +0900
Kohei Takahashi <[email protected]> wrote:
> Hi Lee,
> 
> > How does `fusion::tuple` make `fusion::vector` implementation more
> > complex? Are you referring to the C++03 or C++11 version?  
> C++11 is.
> `fusion::vector` constructors have complex SFINAE expression and
> helper functions in order to sieve its argument category: same type,
> other convertible sequence, nested, ... That is reason why I did tag
> dispatching in `fusion::detail::vector_data`.
>
> I'm still debating about C++03 impl.
> 
> > For C++11 `fusion::tuple` I noticed that if the assignment from
> > fusion sequences was removed (its constructor currently does not
> > allow conversion from sequences and `std::tuple` has no such
> > requirement), then the headers automatically included could be
> > reduced. So `fusion::tuple` _could_ be a faster compiling sequence
> > for when the conversion properties of `fusion::vector` was not
> > needed.  
> Good point. Implicit conversion is one of cause why I proposed.  Since
> `fusion::tuple` uses `fusion::vector`, if this goes on, it can't be
> faster than `fusion::vector`. OK, re-implement `fusion::tuple` without
> any other sequence? Perhaps it has no (or few) difference between
> `fusion::vector` about performance.
> 
> However, no conversion performing guarantee is safer and meaningful
> option for some user.

C++11 `fusion::tuple` inherits from `fusion::vector`. This complicates
the `fusion::vector` implementation because its interface must be
"compatible" with whatever `fusion::tuple` is doing. So if the problem
is the C++11 `fusion::tuple`, I think the short-term solution is to
change its base class to `detail::vector_data`. What happens to
`fusion::tuple` after that is another discussion.

I "injected" the discussion of performance because during my last
patch to fix some bugs posted to the ML, I intentionally re-worked
`vector_data` to be a bit faster and hopefully allow for
`fusion::tuple` to inherit from it directly. I did this because I
noticed if `fusion::tuple` were then made _more_ standard conforming
(by potentially breaking some existing code), headers for interacting
with sequences and `at_c` (via `boost::fusion::get`) could be removed
which should cut down on compile time for people only needing basic
operations. Otherwise (as you noticed), its not exactly clear
when I would use `fusion::tuple` over `fusion::vector` except for
undocumented differences on constructor behavior (assignment is
identical currently!).

> > Of course,
> > since most have a good implementation of `std::tuple` perhaps this
> > unnecessary? I would like to point out that recent tweaks to
> > `fusion::vector` have [improved performance over libstdc++
> > `std::tuple` in construction][0][1].  
> Interesting. I'll try to benchmark simpler impl.
> 
> > Anyway, the bigger issue with deprecation will be on users of Boost.
> > Hopefully the fix would be easy - just change to another sequence
> > type. I'm not aware of an situations where this is _not true_ (i.e.
> > where deprecation would cause major code re-write for Boost
> > users).  
> Yes, I think so too. I'll post this proposal to devel/users ML and ask
> who uses `fusion::tuple` in production code.
> 
> I my mind, just announce in next (or next to the next) release, hence
> no code is changed. After 2 or more release passed, break the code
> (removing, re-implementing, or aliasing).
> 

Lee

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Spirit-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/spirit-general