Re: [boost] [Hana] Formal review for Hana

Subject: Re: [boost] [Hana] Formal review for Hana
From: Paul Fultz II (pfultz2_at_[hidden])
Date: 2015-06-18 17:42:00

> > > I don't know, I just couldn't think of a way to easily implement
something
> > > like the compile-time calculator at [1] using raw SFINAE. I think it
> is
> > > easier
> > > to wrap SFINAE behind an object and to use actual functions to
> manipulate
> > > this
> > > object rather than operating at the SFINAE-level directly, even though
> > > this
> > > surely gives a compile-time benefit. I'm not saying it's impossible,
> I'm
> > > just
> > > saying it needs a lot more creativity than using an Optional object,
> > > especially since C++ programmers will be familiar with the runtime
> concept
> > > when std::optional gets in.
> >
> > Like this here: https://gist.github.com/pfultz2/bfba2bfdca7dec26273c
> «  []
> 
> What happens if you need multiple statements in your functions? You can't
> use auto-deduced return type with your approach, which is a serious
> limitation for doing type-level computations inside functions. I'm not
> saying your approach is wrong, and your implementation of the above is
> very clever, but clearly defining an Optional object which can, in some
> specific cases, represent SFINAE errors, is not wrong either. 

Yes, multiple statements is a limitation of using SFINAE everywhere. And,
btw,
I am not trying to imply that Optional should be taken out of the library.
It
most definitely has its uses.

> > > Overall, I think the idea of using a template to generate
> > > a static site like they do is the best idea and it's the future, but
> I'm
> > > just worried the project might not provide enough features at the
> moment?
> >
> > This is true, and maybe an area where spinx or some other tool(like
> jekyll)
> > might be better.
> 
> What I want is a way to parse C++ code and build some kind of object that
> I
> can access from a Liquid template (I think that's what they use for
> Jekyll).
> Anyway, it will be built one day. 

That sounds like a pretty cool documentation tool, unfortunately, it doesn't
exists today.

> > > make_tuple(int_<1>) compares equal to make_tuple(long_<1>), even
> though
> > > they
> > > have different types. So std::is_same wouldn't be general enough.
> >
> > That doesn't apply here. You just define `tail` to return itself when
> empty.
> 
> I don't understand what you mean. My statement was simply that we couldn't
> implement `equal` as `std::is_same` for compile-time sequences, because
> sometimes two types are different but they should still compare `equal`.
> I used make_tuple(int_<1>) and make_tuple(long_<1>) as an example of two
> such sequences whose types are different, but that should still compare
> equal. 

Because `tail(make_tuple(int_<1>))` will never be `make_tuple(long_<1>)`.
What
matters is that `tail(make_tuple())` returns `make_tuple()`(that is if you
decide to formalize it this way).

Paul

--
View this message in context: http://boost.2283326.n4.nabble.com/Boost-Hana-Formal-review-for-Hana-tp4676969p4677296.html
Sent from the Boost - Dev mailing list archive at Nabble.com.