Overloaded constructors

[vberlier]

I'm a huge fan of your work! I've been experimenting on and off for a couple weeks and I think there's a way to make this work with types that have overloaded constructors.

struct foo {
  foo(float, float) {}
  foo(const char*, int) {}
};

auto a = di::make<foo>(bindings); // currently fails with di::error

The main challenge is enumerating all the possible ways to construct the type. Then we can choose which constructor to invoke based on the available bindings.

The missing piece is something like all_ctors:

struct foo {
  foo() {}
  foo(const foo&) {}
  foo(foo&&) noexcept {}
  foo(float, float) {}
  foo(const char*, int) {}
};

static_assert(all_ctors<foo> == type_list<foo(), foo(const foo&), foo(foo&&), foo(float, float), foo(const char*, int)>{});

The way I'm trying to make this work is that instead of any extracting a single possible argument type with bind<arg<B, N>, T>{}, we could make every instantiation of the implicit conversion operator append the deduced type to a stateful list.

Overloaded constructors fail because the call is ambiguous. But the overload resolution failure still instantiates every possible implicit conversion for each argument, making it theoretically possible to sfinae while extracting all possible types deduced by the compiler.

This leaves us with a list of possible types for each argument position of a given constructor arity. We can then generate all the possible type combinations and check which invocations are actually valid.

Unfortunately, it gets quite complicated, and I'm a bit stuck. I'm pretty confident the idea would actually work but I probably still don't fully understand all the details. I'm curious if you see any immediate problem with this approach. Did you ever consider something like this? How would you go about it?

[kris-jusiak]

Thanks for the inspiring comment @vberlier. Apologies for the late reply, I've been thinking of it and I also believe that' possible and actually pretty cool. I think that has be done during overload resolution inside a concept together with the registration via friend injection during evaluation. Maybe something similar to https://godbolt.org/z/Ph5e8P37T.