[ 2022-10-12 LWG telecon ]

Discussed on reflector in July 2022, no consensus on how observer_ptr is even meant to be used.

shared_ptr supports function types, no good reason to disallow them here.

No desire to make any change for LFTSv3, but keep the issue open until/unless the TS is withdrawn. That way we will be less likely to forget about this if observer_ptr is propsed for the IS.

[ 2018-11 Reflector prioritization ]

Set Priority to 3

Addresses: fund.ts.v3

From the wording, function pointers are never clearly considered. P1 infers support for only objects, but it is not clear that wording is intended to be a deliberate restriction, or is casual wording.

Paragraph 2 mandates that we cannot instantiate for reference types, and do support incomplete types, but still does not consider function types. Calling out references specifically, as they are not object types, suggests the inferred support for only objects in p1 is more a case of casual phrasing, than deliberate intent.

However, if we did intend to support function pointers, we may want to consider adding a function-call operator, constrained to supporting pointer-to function types. One other possibility is that the explicit conversion to pointer already serves that purpose, although I need to double-check the core language that contextual conversions to function pointer are considered when invoking the function call operator. If this is the case, then I suggest a note to that effect in [memory.observer.ptr.conv] instead.