Variadic template only compiles when forward declared

Question

I have a variadic template that inherits from all template arguments:

template <typename... Ts>
struct derived : Ts...
{
};

I would also like to have a facility for expressing the type of "existing derived with added template arguments". My attempt at this is:

// Do not ODR-use (goes in namespace impl or similar)!
template<class ... NewInputs, class ... ExistingInputs>
auto addedHelper(const derived<ExistingInputs...>&)
    -> derived<ExistingInputs..., NewInputs...>;

template<class ExistingInput, class ... NewInputs>
using Added = decltype(addedHelper<NewInputs...>(std::declval<ExistingInput>()));

As a simple example, Added<derived<A, B>, C> should be derived<A, B, C>. I use the helper function for template argument deduction of the first parameter pack.

My problem: For some reason, I can use this successfully with incomplete types if derived has been forward declared, but not if it was defined.

Why does this code not compile:

#include <utility>

template <typename... Ts>
struct derived : Ts...
{};

template<class ... NewInputs, class ... ExistingInputs>
auto addedHelper(const derived<ExistingInputs...>&)
    -> derived<ExistingInputs..., NewInputs...>;

template<class ExistingInput, class ... NewInputs>
using Added = decltype(addedHelper<NewInputs...>(std::declval<ExistingInput>()));


struct A;
struct B;
struct C;

// Goal: This forward declaration should work (with incomplete A, B, C).
auto test(derived<A, B> in) -> Added<decltype(in), C>;


struct A {};
struct B {};
struct C {};

void foo()
{
    auto abc = test({});

    static_assert(std::is_same_v<decltype(abc), derived<A, B, C>>, "Pass");
}

Whereas this code does compile:

#include <utility>

template <typename... Ts>
struct derived;


template<class ... NewInputs, class ... ExistingInputs>
auto addedHelper(const derived<ExistingInputs...>&)
    -> derived<ExistingInputs..., NewInputs...>;

template<class ExistingInput, class ... NewInputs>
using Added = decltype(addedHelper<NewInputs...>(std::declval<ExistingInput>()));


struct A;
struct B;
struct C;

// Goal: This forward declaration should work (with incomplete A, B, C).
auto test(derived<A, B> in) -> Added<decltype(in), C>;


template <typename... Ts>
struct derived : Ts...
{};


struct A {};
struct B {};
struct C {};

void foo()
{
    auto abc = test({});

    static_assert(std::is_same_v<decltype(abc), derived<A, B, C>>, "Pass");
}

For convenience, here are both cases at once (comment in/out #define FORWARD_DECLARED): https://godbolt.org/z/7gM52j

I do not understand how code could possibly become illegal by replacing a forward declaration by the respective definition (which would otherwise just come later).

Observation: GCC accepts the code if you add `::`: `using Added = decltype(::addedHelper...`. — Evg, Jun 21 '19 at 12:43
@Evg Ok what the hell... ADL rears its ugly head once again. — Max Langhof, Jun 21 '19 at 12:48
I think it is unspecified if instantiation in un-evaluated context might happens. — Jarod42, Jun 21 '19 at 12:48
@MaxLanghof before and after `derived` has a body. Calling `test`. — Yakk - Adam Nevraumont, Jun 21 '19 at 13:58
@Yakk-AdamNevraumont Do you mean that `derived` is ODR-used in the `test` forward declaration? Good point, I'm only using references to `derived` originally though, so that shouldn't be a problem. — Max Langhof, Jun 21 '19 at 14:06

Barry · Accepted Answer · 2019-06-21T15:50:45.443

8

Evg's observation hits the nail on the head: the problem here is ADL. It's actually the same problem I ran into with this question.

The issue is this: we have an unqualified call here:

template<class ExistingInput, class ... NewInputs>
using Added = decltype(addedHelper<NewInputs...>(std::declval<ExistingInput>()));
//                     ^^^^^^^^^^^

We know it's a function template because we find it in using regular lookup, so we don't have to deal with the whole "is < an operator or a template introducer" question. However, because it's an unqualified call, we also must perform argument-dependent lookup.

ADL needs to look into the associated namespaces of all the arguments, which seems fine - we don't need complete types for that. But ADL also needs to look for potential friend functions and function templates defined within the classes. After all, this needs to work:

struct X {
    friend void foo(X) { }
};
foo(X{}); // must work, call the hidden friend defined within X

As a result, in our call in question:

auto test(derived<A, B> in) -> Added<decltype(in), C>;

We have to instantiate derived<A, B>... but that type inherits from two incomplete classes, which we can't do. That's where the problem is, that's where we fail.

This is why the forward declaration version works. template <typename... T> struct derived; is incomplete, so just trying to look inside of it for friend functions trivially finds nothing - we don't need to instantiate anything else.

Likewise, a version where derived was complete but didn't actually derive from anything would also work.

Thankfully, this is fixable in this context with what Evg suggested. Make a qualified call:

template<class ExistingInput, class ... NewInputs>
using Added = decltype(::addedHelper<NewInputs...>(std::declval<ExistingInput>()));

This avoids ADL, which you didn't even want. Best case, you're avoiding doing something that has no benefit to you. Bad case, your code doesn't compile. Evil case, for some inputs you accidentally call a different function entirely.

Or just use Boost.Mp11's mp_push_back

edited Jun 21 '19 at 15:50

answered Jun 21 '19 at 13:46

Barry

286,269
29
621
977

1

But Clang reject the code even with `::`. That's why I mentioned GCC explicitly. – Evg Jun 21 '19 at 13:51
@Oliv, did you miss `friend` there? – Evg Jun 21 '19 at 13:54
@Evg Indeed! Related question: is [this code](https://godbolt.org/z/tlaLzm) ill-formed? – Oliv Jun 21 '19 at 13:55
@Oliv note that your question does not seem to involve ADL. – Igor R. Jun 21 '19 at 15:10
So the snippet with forward declaration is also incorrect (even if it compiles)? – Jarod42 Jun 21 '19 at 15:11
@Oliv No it's not, and I fixed my answer -- right general idea, but had the wrong specifics before. – Barry Jun 21 '19 at 15:23
Note that the ADL lookup that `so just trying to look inside of it for friend functions trivially finds nothing` could lead to ODR violations I expect; a lookup where the template *is* complete and so are the base types would lead to a different result from it. And that is usually ODR-toxic. – Yakk - Adam Nevraumont Jun 21 '19 at 16:26
@Yakk-AdamNevraumont Yeah such things are ill-formed, NDR. – Barry Jun 21 '19 at 17:40
Good catch on the ADL part; I just want to mention why Clang rejects the code even with `::`: [\[temp.deduct.call\]/4](http://eel.is/c++draft/temp.deduct.call#4). Clang is arguably right: the wording seems to say (in the next paragraph) that those alternatives are all-or-nothing; whether that makes sense in cases such as this one is another question... Solution: `addedHelper(derived&&)`, to avoid the alternatives altogether. cc @Evg – bogdan Jun 22 '19 at 17:08
I ended up going with the template specialization approach that Boost.MP uses. That also feels cleaner than using a function without definition... – Max Langhof Jun 25 '19 at 07:37

Variadic template only compiles when forward declared

1 Answers1