将赋值运算符实现为"destroy + construct"是否合法？

我经常需要为"原始"资源句柄(如文件句柄、Win32操作系统句柄等)实现C++包装器。在执行此操作时，我还需要实现move运算符，因为默认编译器生成的运算符不会清除moved-from对象，从而产生双重删除问题。

在实现move赋值操作符时，我更喜欢显式调用析构函数，并使用placement new就地重新创建对象。这样，我就避免了析构函数逻辑的重复。此外，我经常以复制+移动(在相关情况下)的方式实现复制分配。这导致以下代码：

/** Canonical move-assignment operator. 
Assumes no const or reference members. */
TYPE& operator = (TYPE && other) noexcept {
if (&other == this)
return *this; // self-assign
static_assert(std::is_final<TYPE>::value, "class must be final");
static_assert(noexcept(this->~TYPE()), "dtor must be noexcept");
this->~TYPE();
static_assert(noexcept(TYPE(std::move(other))), "move-ctor must be noexcept");
new(this) TYPE(std::move(other));
return *this;
}
/** Canonical copy-assignment operator. */
TYPE& operator = (const TYPE& other) {
if (&other == this)
return *this; // self-assign
TYPE copy(other); // may throw
static_assert(noexcept(operator = (std::move(copy))), "move-assignment must be noexcept");
operator = (std::move(copy));
return *this;
}

这让我觉得很奇怪，但我还没有在网上看到任何关于以这种"规范"方式实现move+copy赋值运算符的建议。相反，大多数网站倾向于以特定类型的方式实现赋值运算符，必须手动与构造函数保持同步；析构函数。

除了性能之外，还有什么反对实施move&以这种与类型无关的"规范"方式复制赋值运算符？

更新2019-10-08基于UB评论：

我已经通读了http://eel.is/c++draft/basic.life#8似乎涵盖了所讨论的案例。摘录：

如果在对象的生存期结束后。。。，一个新对象是在原始对象占用的存储位置创建，a指向原始对象的指针，引用到原始对象。。。将自动引用新对象。。。，可以用于操作新对象，如果。。。

之后有一些明显的条件与相同的类型和const/reference成员相关，但它们似乎是任何赋值运算符实现所必需的。如果我错了，请纠正我，但在我看来，我的"规范"样本表现良好，而不是UB(？)

更新2019-10-10基于复制和交换评论：

赋值实现可以合并到一个方法中，该方法采用值参数而不是引用。这似乎也消除了对static_assert和自分配检查的需要。我提出的新实施方案变成：

/** Canonical copy/move-assignment operator.
Assumes no const or reference members. */
TYPE& operator = (TYPE other) noexcept {
static_assert(!std::has_virtual_destructor<TYPE>::value, "dtor cannot be virtual");
this->~TYPE();
new(this) TYPE(std::move(other));
return *this;
}