consume_t template

[meirumeiru]

what's the purpose of the consume_t template class? I don't understand how it works

that's the first things I found and copied out...

`template
struct consume;
template
struct consume_IInterface
{
[[nodiscard]] WINRT_IMPL_AUTO(hstring) Verb() const;
};
template <> struct consume
{
template using type = consume_IInterface;
};

template <typename D, typename I = D>
using consume_t = typename consume::template type;

template <typename D, typename I>
struct require_one : consume_t<D, I>
template <typename D, typename... I>
struct __declspec(empty_bases) require : require_one<D, I>...
{};`

...
now, I see multiple classes defined as

struct something : require<something, IInterface>
{}

so, let's analyze it... first, require does derive from every passed interface by using require_one... that's the easy part. Then consume_t is used and here I don't see what the purpose is... it's inheriting from a inner template class of the "consume" template class? ... why? what's the purpose of it? ... I didn't find the corresponding code that explains this.
And then... what's the purpose of the finally inherited class? Does it do anything?

What's this "Verb" function doing they added? ... ah, this one I see now... it's the function defined in the IInterface... but IInterface does inherit other interfaces... where are the functions of these interfaces? ... hmm ... maybe somewhere else

... and still... why is it done the way it is done? what's the deeper purpose? why not directly generating the classes without those thousands of template classes in between? and why this inheritance of an inner class? ... I cannot imagine they do this for fun

[jonwis]

Hey @kennykerr or @DefaultRyan - this should probably move to http://github.com/microsoft/cppwinrt ? I don't have Transfer rights.

[kennykerr]

We don't have a discussion area for cppwinrt. We generally refer folks to the docs or to https://stackoverflow.com/ for general questions like this. Briefly, C++/WinRT is internally implemented in terms of CRTP. This allows different concrete types to inherit the functionality via static polymorphism, but this is an implementation detail that may one day disappear. For example, C++23 had proposed a language feature that would deduce this in the context of static polymorphism and eliminate the need for CRTP but that feature has, from what I hear, slipped to some future standard.