Perhaps another LWG issue is needed to add constraints to the assignment operator template.

@jwakely , do we have those LWG issues?

The move assignment operator is intentionally not noexcept, to leave room for an allocator-aware move_only_function in future, which might need to allocate.

Perhaps another LWG issue is needed to add constraints to the assignment operator template.

No, because it already has the constraints from the constructor, through the use of "Effects: Equivalent to ..."

I think this can be closed.

See [structure.specifications] p4.

Perhaps another LWG issue is needed to add constraints to the assignment operator template.

No, because it already has the constraints from the constructor, through the use of "Effects: Equivalent to ..."

So is it intentional that assigning std::in_place_type<int(*)()> to a std::move_only_function<int()> is permitted?

The wording in the paper reflects the design that was approved. If you think the design was wrong, please file an LWG issue.

I find it very hard to care about code that does f = std::in_place_type<int(*)()> because that seems very unlikely to happen by mistake, and if you want to do something so silly, then go ahead.

This also compiles fine, despite being useless and silly:

std::move_only_function<int()> f(std::in_place_type<int(*)()>);

If you want to store a null pointer you can do so with nullptr, or with silly nonsense like this. 🤷

Oh, although the "*this has a target object unless any of the following hold" condition only applies to the move_only_function(F&&) constructor, so constructing from std::in_place_type<int(*)()> creates a target object (i.e. a non-empty move_only_function) that will crash if called. That's not an issue with the assignment operator though. And it's also seems like a case where "play stupid games, win stupid prizes" applies.