Implement C++ assignment operator in terms of constructor

Question

Background

Suppose you want to implement a resource-managing class in C++. You cannot use the Rule of Zero or Rule of Five Defaults, so you actually need to implement copy and move constructor, copy and move assignment operator, and destructor. In this question, Iʼll use Box as an example, but this can apply to lots of different types.

// Store object on heap but keep value semantics
// Moved-from state has null elem; otherwise should have value
// Only valid operations on moved-from state are assignment and destruction
// Assignment only offers a basic exception guarantee
template <typename T>
class Box {
public:
    using value_type = T;

    // Default constructor
    Box() : elem{new value_type} {}
    // Accessor
    value_type& get() { return *elem; }
    value_type const& get() const { return *elem; }

    // Rule of Five
    Box(Box const& other) : elem{new value_type{*(other.elem)}} {};
    Box(Box&& other) : elem{other.elem}
    {
        other.elem = nullptr;
    };
    Box& operator=(Box const& other)
    {
        if (elem) {
            *elem = *(other.elem);
        } else {
            elem = new value_type{*(other.elem)};
        }
        return *this;
    }
    Box& operator=(Box&& other)
    {
        delete elem;
        elem = other.elem;
        other.elem = nullptr;
        return *this;
    }
    ~Box()
    {
        delete elem;
    }

    // Swap
    friend void swap(Box& lhs, Box& rhs)
    {
        using std::swap;
        swap(lhs.elem, rhs.elem);
    }
private:
    T* elem;
};

(Note that a better Box implementation would have more features like noexcept and constexpr functions, explicit forwarding constructors based on value_typeʼs constructors, allocator support, etc; here Iʼm implementing just whatʼs necessary for the question and the tests. It might also save some code with std::unique_ptr, but that would make it a less-clear example)

Note that the assignment operators share lots of code with each other, with their respective constructors, and with the destructor. This would be somewhat lessened if I didnʼt want to allow assignment to moved-from Boxen, but would be more apparent in a more complicated class.

Digression: Copy-and-Swap

One standard way of handling this is with the Copy-And-Swap Idiom (also in this context called the Rule of Four and a Half), which also gets you a strong exception guarantee if swap is nothrow:

    // Copy and Swap (Rule of Four and a Half)
    Box& operator=(Box other)  // Take `other` by value
    {
        swap(*this, other);
        return *this;
    }

This allows you to write only one assignment operator (taking other by value lets the compiler move the other to the parameter if possible, and does the copying for you if necessary), and that assignment operator is simple (assuming you already have swap). However, as the linked article says, that has issues such as doing an extra allocation and keeping extra copies of the contents around during the operation.

The Idea

What I havenʼt seen before is something Iʼll call a Destroy-and-Initialize assignment operator. Since weʼre already doing all the work in the constructor, and an assigned-to version of the object should be identical to a copy-constructed one, why not use the constructor, as follows:

    // Destroy-and-Initialize Assignment Operator
    template <typename Other>
    Box& operator=(Other&& other)
    requires (std::is_same_v<Box, std::remove_cvref_t<Other>>)
    {
        this->~Box();
        new (this) Box{std::forward<Other>(other)};
        return *std::launder(this);
    }

This still does an extra allocation like Copy-and-Swap does, but only in the copy assignment case instead of the move assignment case, and it does it after destroying one of the copies of T, so it doesnʼt fail under resource constraints.

Questions

1. Has this been proposed before, and if so where can I read more about it?
2. Is this UB in some cases, such as if the Box is a subobject of something else, or is it allowed to destroy and re-construct subobjects?
3. Does this have any downsides I havenʼt mentioned, like not being constexpr compatible?
4. Are there other options to avoid assignment operator code reuse, like this and the Rule of Four and a Half, when you canʼt just = default them?