On Wed, Dec 10, 2025 at 2:40 PM Bjorn Reese wrote:
>
> On 12/8/25 23:56, Frederick Virchanza Gotham wrote:
> >
> > I reply in series below to Jeremy and Bjorn.
>
> Please respond in separate mails in the future. Otherwise it becomes
> difficult to follow the discussions.


I thought it would make things less cluttered if I squished 3 posts
into 1 instead of posting separately three times. Do others agree that
it's preferable to send separate posts?


> This change has implications for other standard facilities, because
> the chimeric pointer does not really behave like a (smart) pointer.
> For example, any facility using the INVOKE requirement [func.require]
> fails, such as std::invoke(&Editor::Edit, ptr), where ptr is a
> chimeric_ptr.


Today I'm working on a specialisation of 'std::invoke'. I might have
it working tomorrow.


> As another example, std::to_address(ptr) fails with a
> confusing error message.


I have to consider, what address should be returned from 'to_address'?
I think what makes most sense is that it would return the address of
the first interface (i.e. the first interface mentioned left to right
when specifying template parameters to chimeric_ptr). The only other
half-sane alternative would be that it returns the address of the
object supplied to the constructor -- but the pointer type would be
'void*' so you wouldn't be able to do much with it at all --
especially on the Microsoft compiler because you aren't guaranteed
that a polymorphic object's vptr is at offset zero, and also on Apple
Silicon arm64e where you won't be able to read the vtable at all if
you don't know the type T do decrypt its vptr.