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

is_copy_constructible should be a trait defaulting to std::is_copy_constructible #1653

Open
deadlocklogic opened this issue Nov 27, 2024 · 2 comments

Comments

@deadlocklogic
Copy link
Contributor

deadlocklogic commented Nov 27, 2024

Consider: this thread
And this example:

struct NonCopyable {
    NonCopyable() = default;
    ~NonCopyable() {}
private:
    std::unique_ptr<int> value;
};
template <typename T>
struct Wrapper {
    Wrapper() = default;
    Wrapper(const Wrapper&) = default;
    Wrapper(Wrapper&&) = default;
    T* v = nullptr;
};

Wrapper<NonCopyable> globalFunction() { return {}; }

and registering globalFunction with:

lua["globalFunction"] = &globalFunction;

Compiling with clang gives: call to implicitly-deleted copy constructor of 'Wrapper<NonCopyable>', so sol is relying on std::is_copy_constructible which should be generally enough (enough for non templated types).
But for types like the example above, we can use a specialized trait to modify the behavior (quite smooth if we are using a custom code generator).

sol documentation should shed some light on type traits, especially the comparison traits because for wrapped types (not pushed as custom types), we can't rely on std <type_traits> alone.

@deadlocklogic
Copy link
Contributor Author

deadlocklogic commented Nov 27, 2024

The move constructor is implicitly deleted, so the type wasn't copyable or movable.
Here is a repro

@deadlocklogic
Copy link
Contributor Author

The problem is that I can't make a simple repro where a type has a copy constructor implicitly deleted but is movable.
I know my example is broken, but my problem is occurring in a large codebase. If further repro is needed I can create it.

So basically a type with implicitly deleted copy constructor can't be binded with clang.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant