This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD status.

### 2886. Keep the `empty()` functions in `any`

Section: 20.8.4.5 [any.observers] Status: NAD Submitter: Finland Opened: 2017-02-03 Last modified: 2020-09-06

Priority: Not Prioritized

View all issues with NAD status.

Discussion:

Addresses FI 7

The proposal p0032 has multiple problems: 1) it turns member function `.empty()` into `.has_value()`, negating the logic. Refactoring e.g. existing uses of `std::experimental::any` to use `std::any` thus involve non-trivial refactorings that are error- prone and can't be done via simple search-and-replace if there are containers in the same source files for which `.empty()` is used (based on the implementation experience of making the change in libstdc++ and refactoring the testsuite). Whilst `any` is not a container, the library is failing to go towards a direction where there would be a generic way to query for emptiness. 2) The use of function references for tag types makes the interface hard to use. The tag types do not have value semantics like every other tag type has, the tag types are hard to construct, and present surprises for certain kinds of overload sets. Furthermore, any attempts to decay the tag types produces a really surprising effect — as opposed to what the other tag types do, which is that the result of decaying them is the tag type itself, decaying these new tag types results in a pointer to function.

Proposed change: Keep the `.empty()` functions (and introduce them to all the types that are supposed to have a homogeneous interface), and make the tag types be regular tag types that are not references to functions.

[2017-02-03, Marshall notes]

P0504R0 (adopted in Issaquah) removed use of function references for tag types

[ 2017-06-26 Moved to Tentatively NAD after 5 positive votes on c++std-lib. ]

Proposed resolution: