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
> > > like the compile-time calculator at  using raw SFINAE. I think it
> > > easier
> > > to wrap SFINAE behind an object and to use actual functions to
> > > 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,
> > > just
> > > saying it needs a lot more creativity than using an Optional object,
> > > especially since C++ programmers will be familiar with the runtime
> > > 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,
I am not trying to imply that Optional should be taken out of the library.
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
> > > just worried the project might not provide enough features at the
> > This is true, and maybe an area where spinx or some other tool(like
> > might be better.
> What I want is a way to parse C++ code and build some kind of object that
> can access from a Liquid template (I think that's what they use for
> Anyway, it will be built one day.
That sounds like a pretty cool documentation tool, unfortunately, it doesn't
> > > make_tuple(int_<1>) compares equal to make_tuple(long_<1>), even
> > > 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
> 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
Because `tail(make_tuple(int_<1>))` will never be `make_tuple(long_<1>)`.
matters is that `tail(make_tuple())` returns `make_tuple()`(that is if you
decide to formalize it this way).
-- 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk