Paul Fultz II
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