On 4/2/26 18:06, Keenan Horrigan wrote:
> Actually, forgive me if I'm reading this incorrectly, but I'm only seeing a change for block-scope function declarations in the 2025-11-06 proposed resolution, which is listed as superseded. And I'm not seeing anything in the approved 2026-01-09 resolution pertaining to block-scope function declarations.
>
> Are they maybe touched on indirectly/implicitly? My standardese might be lacking in that regard.

Third change:

Add a bullet after 7.6.2.10 [expr.reflect] bullet 5.7 as follows:

"Otherwise, if lookup finds a declaration whose host scope is different from its target scope, R is ill-formed."

This is the standardese encoding of "block-scope extern (variable or function declaration);
the latter might lack the extern".

Jens


> Thanks
>
> On Thursday, April 2nd, 2026 at 10:59 AM, Keenan Horrigan <friedkeenan_at_[hidden]> wrote:
>
>> Ah, shame. Thanks for the answer, though.
>>
>> On Thursday, April 2nd, 2026 at 4:03 AM, Jens Maurer <jens.maurer_at_[hidden]> wrote:
>>
>>>
>>>
>>> On 4/2/26 05:48, Keenan Horrigan via Std-Discussion wrote:
>>>> On Clang you can even have
>>>>
>>>> template<typename T>
>>>> consteval auto get_function() {
>>>> void function(T);
>>>>
>>>> return ^^function;
>>>> }
>>>>
>>>> And then get at the overload generically like 'get_function<int>()'. GCC currently runs into an internal error with that, though: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124756
>>>>
>>>> But basically, I was wondering if this is valid behavior or not. It would be potentially useful, since I'm not aware of another way to get a reflection of a particular overload from an overload set. But I'm unsure if I could rely on this behavior.
>>>
>>> EWG decided to make it ill-formed to apply the reflection operator to block-scope
>>> extern declarations; see CWG 3065.
>>>
>>> https://cplusplus.github.io/CWG/issues/3065.html
>>>
>>> Jens
>>>