Interfaces core.hpp and tuple_size.hpp no more has aliases

[denzor200]

In C++ we can't make specialization for type alias, but for structure can. This PR will make https://github.com/boostorg/pfr/issues/100 possible to implement.

[coveralls]

Pull Request Test Coverage Report for Build 2972180814

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 100.0%

---

Totals
Change from base Build 1768569863:	0.0%
Covered Lines:	337
Relevant Lines:	337

---

💛 - Coveralls

[apolukhin]

What is the purpose of specializing those two structures?

[denzor200]

What is the purpose of specializing those two structures?

Those two structures are not intended to specialize by library's user(i wrote a note in the docs about it, just now). Ability to specialize will be used by library developers.

[denzor200]

What is the purpose of specializing those two structures?

It may reduce a lot of code, when i continue integrating pfr into fusion using "VIEW manipulator", like this:

struct A
struct B;
struct C;

BOOST_PFR_REGISTRATE_REFLECTABLE(B)

A a{};
B b{};
C c{};
// boost::fusion::for_each(a, [](auto&&){});                     // won't compile
boost::fusion::for_each(b, [](auto&&){});                        // will use default specialization inside
boost::fusion::for_each(boost::pfr::view(c), [](auto&&){});      // will use `boost::pfr::tuple_size<boost::pfr::view_impl<B>>` specialization inside

See https://github.com/boostorg/pfr/issues/100 for more detail about BOOST_PFR_REGISTRATE_REFLECTABLE macro and boost::pfr::view manipulator

[denzor200]

Not actual. It may be reopened in the future when we decide that we really need 'boost::pfr::view' or 'boost::pfr::view_fields', but not now.