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

Subject: Re: [boost] [Hana] Formal review for Hana
From: Louis Dionne (ldionne.2_at_[hidden])
Date: 2015-06-18 13:22:45

Paul Fultz II <pfultz2 <at> yahoo.com> writes:

>
> > 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.

> [...]
> > Also, is there some cross-referencing going on in the source code, so
> > links
> > are generated automatically?
>
> I am not quite sure what you mean, but you can cross reference other pages.

Sorry, I meant that names in the code should generate links to their
documentation.

> > 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.

> > 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.

Regards,
Louis