template< int N > struct tuple_element<N,foo>...

Should be

template<size_t N> struct tuple_element<N,foo>...

I've never used a type with "byte" in its name except the one for Win32 APIs: BYTE. However, I have used char, uint8_t, etc., to mean a byte type. Having a byte_t would be better as it would be semantically correct and would be portable to any remaining platforms with non-8-bit bytes.

I'd like to use part of the content here in my presentation (with proper credit, of course). There is no explicit license currently mentioned in the repo and the mentioning of your employer makes me worry even more about the possible copyright issues...
It'd be great if you could please consider adding a license (or at least clarify it in README).

Thank you for the link to the ALL_IN_ONE.md and the work behind it. What a great read, I wish I knew it existed before!

By usage, I found one thing that's hard/awkward with std::variant is when your types aren't defaulted constructible (or when you want an option for the case where it's not initialized (optional)), with the use of std::monostate. Perhaps adding a small bit about this would be good?

I realize this isn't meant to replace actual documentation but rather get to the point (and it's doing an awesome job at it!), so perhaps that would be considered clutter, I'm not sure.

Based on your source Structured Bindings :
auto [ a, b ] = stuff()
a and b variables is going to be value types instead of references.

correct compiled code is :
auto __tmp = stuff(); auto i = get<0>(__tmp); auto s = get<1>(__tmp);

adding reference example could clean up the idea behind Structured Bindings and why we needed the new syntax. ie: reference can not be obtained with std::tie.

Hi
I'm not sure if you didn't mean C++11 in the first column of the table. Well, it's right to put C++14, as it should be valid C++14, but I was just wondering.
I hope I'm not wasting your time with this. I'm just learning :)
Thanks,
Juraj

C++14 code in examples in Constexpr If is not valid code. For instance the return type should be at least const auto&.
Also the claim about the usage of get<>() for user defined type is not complete. The specialization of std::tuple_size and std::tuple_element has to be provided.

The parallel execution policies are live in the std::execution namespace not plain std, unless something changed that I missed.

The Tony Table for std::any says that any it does not require calls to new.

I think that's a bit misleading. The object still needs to be stored somewhere, and the only way to avoid storing it on the heap is to use a small-object optimization, which only applies to objects that are sufficiently small (in the libcxx implementation, 3 words in size or smaller).

// nicer with new if syntax:
if (optional ofoo = parseFoo(str); ofoo)
   use(*ofoo);

Even nicer, old style, without the extraneous ofoo conditional?

if (optional ofoo = parseFoo(str))
   use(*ofoo);

Old style if could always be a single declaration,
new style needed for more complex cases.

We could argue the ifs and buts.

The indenting in your examples is confused, whether I view it from my github account or anonymously.

My theory is that you are mixing tabs and spaces, and your tab stops are different from GitHub's default tab stops. :-)

The screen shot shows one example, but a similar problem appears on nearly all of them.

Thanks for this great resource!