Consider making rust::Box constructors `explicit` about cxx HOT 2 CLOSED

Thanks! I agree that an implicit construction from char const* to rust::String should be fine. I ended up changing only these two constructors:

explicit Box(const T &val);
explicit Box(T &&val);

which is consistent with there being no implicit constructor from T to unique_ptr<T>.

from cxx.

in C++20, we have the option of making constructors conditionally explicit. This could be one path to take.explicit means that doing something like

rust::String some_function () {
  return { "hello" };
}

Will not compile. If you want these to be 'free-form', then it might stand to make them implicit.

That said, C++17's std::string has added a constructor which is explicit and is for converting between any T provided the following:

Implicitly converts t to a string view sv as if by std::basic_string_view<CharT, Traits> sv = t;, then initializes the string with the contents of sv, as if by basic_string(sv.data(), sv.size(), alloc). This overload only participates in overload resolution if std::is_convertible_v<const T&, std::basic_string_view<CharT, Traits>> is true and std::is_convertible_v<const T&, const CharT*> is false.

I will say that while some C++ committee folks are against implicit constructors, I tend to permit them for 'basic' types, even from other languages. (after all, if I return "hello" from a C++ function that is being called by Python, it would stand to reason that I want it to be a python string, not a C char const*).

That said, however, std::unique_ptr has an explicit constructor for taking a single pointer, but make_unique, and make_unique_for_overwrite are provided to 'get around' this option. (However, this is because make_unique is the default 'use new T(std::forward<Args>(args)...)', while unique_ptr(pointer) is provided to allow you to allocate from wherever. Since allocators aren't stabilized in Rust yet, it's not really an issue on that side of things, but it's something to keep in mind, I suppose. 🙂

from cxx.