Re: [boost] [metal] Feature Complete - Request for Feedback

Subject: Re: [boost] [metal] Feature Complete - Request for Feedback
From: paul (pfultz2_at_[hidden])
Date: 2017-02-22 23:11:54

On Wed, 2017-02-22 at 19:35 +0100, Bruno Dutra wrote:
> On Wed, Feb 22, 2017 at 2:33 AM, Paul Fultz II via Boost <boost_at_lists
> .boost.org> wrote:
> > 
> > > On Feb 21, 2017, at 1:16 PM, Bruno Dutra via Boost <boost_at_lists.b
> > oost.org> wrote:
> > >
> > >
> > > Your example is implemented in Metal like this
> > >
> > > using _ = metal::transform<metal::lambda<std::add_const_t>,
> > > metal::as_list<std::shared_ptr<X>>>; // metal::list<X const>
> > > metal::apply<metal::lambda<std::shared_ptr>, _> //
> > std::shared_ptr<X const>
> > >
> > > Admittedly a bit verbosier, but not too bad.
> > > .
> > 
> > I like this. Its explicit and fast, which I think is good for
> > something that is core. From there you could build other frontends
> > that simplify it more by deducing the explicit types and then
> > passing them to the core components.
> Exactly. Thanks for your feedback!
> Â Â 
> > Another thing I saw is that you no longer support gcc 4.8. Why is
> > that? As a core library, I would expect good portability, since the
> > portability limitations don’t just affect Metal but also any
> > libraries that decide to use it(or perhaps replace mpl with it).
> That is a very good point. I've strived to support the widest variety
> of compilers throughout the development of Metal and spent a _lot_ of
> time, working around nasty compiler bugs. It is kindda sad, but by
> now I'm sure I could ICE either GCC, Clang or MSVC at will. Simply
> put, at some point I just gave up on hammering Metal down on older
> GCC versions. 
> 
> I just tried to running Metal test suite on GCC 4.9 and it fails the
> 3rd test of 200 already. According to the error log, it can't SFINAE
> away invalid instantiations of a template that expects N arguments
> but was given less than that.
> 
> It most probably can be worked around by decltyping a an overloaded
> function call, but that kills performance and I'll have to #ifdef it,
> which sucks TBH. Nevertheless I'll give it a
> shot https://github.com/brunocodutra/metal/issues/59

I think picking a slower implementation on older compilers is
acceptable. This way I can develop with newer compilers which are fast,
and deploy with the older compilers. Also, having a faster compilation
with newer compilers is a good way to convince management to move to a
newer compiler.

> 
> > Ideally, it would be nice if it supported gcc 4.6(even only
> > partially), as I would use it in my Tick library and get rid of my
> > homebrew metaprogamming. However, I know that might be a lot of
> > work since gcc 4.6 doesn’t have template aliases.
> Sadly without alias templates there's not much I could do :(

Well on gcc 4.6 inheritance can be used instead of an alias, but then
you would need an evaluation step, like:

METAL_EVAL(metal::drop<l3, metal::number<3>>)

And then the library would need to apply these evaluations internally
as well. I don't know know if you would accept a PR with changes to
support gcc 4.6 or not. Of course the first thing is to support for gcc
4.8 and then we could move backwards toward 4.7 and then 4.6.

Paul