Skip to content

Overloaded constructors #2

@vberlier

Description

@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?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions