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-tp46769... Sent from the Boost - Dev mailing list archive at Nabble.com.