Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't really construct a box with non-list initialization #155

Open
tusooa opened this issue Aug 19, 2020 · 2 comments
Open

Can't really construct a box with non-list initialization #155

tusooa opened this issue Aug 19, 2020 · 2 comments
Labels

Comments

@tusooa
Copy link

tusooa commented Aug 19, 2020

Currently we have 3 ways to initialize a box with value T{...} but no way to initialize one with value T(...). These causes problems for types with a constructor that takes a std::initializer_list. For example, the following prints out 2 50 2:

struct test
{
    test(int a) : a(a) {}
    test(const test& that) : a(that.a) {}
    test(test &&that) : a(that.a) {}
    template<class T>
    test(const std::initializer_list<T> &l) {
        a = 50;
    }
    int a;
};
int main()
{
    test t1(2);
    immer::box<test> t2(t1);
    test t3(t1);
    std::cout << t1.a << std::endl << t2.get().a << std::endl << t3.a << std::endl;
}

A real-life example would be https://github.com/nlohmann/json, for which the list initialization wraps whatever passed to it into a JSON array.

I think we need to have some strategy to differentiate between these two.

@tusooa tusooa changed the title Can't really construct a box with a known value of value type Can't really construct a box with non-list initialization Aug 19, 2020
@arximboldi
Copy link
Owner

Ohhh, damn initializer lists. What compilation error are you getting? That case is intended to work. I think I can figure a way to fix that particular case by specifically distinguishing copy/move constructing the underlying T.

@tusooa
Copy link
Author

tusooa commented Aug 19, 2020

Ohhh, damn initializer lists. What compilation error are you getting? That case is intended to work. I think I can figure a way to fix that particular case by specifically distinguishing copy/move constructing the underlying T.

Not a compilation error, but I have no way to invoke the other constructors than the one taking an initializer_list.

@arximboldi arximboldi added the bug label Nov 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants