I reply in series below to Jeremy and Bjorn.


On Mon, Dec 8, 2025 at 6:25 PM Jeremy Rifkin wrote:
>
> “We introduce” - you and Thomas Healy? If so, all authors should be listed.


It's the royal 'we'. For the time being I'm the only author but I'll
be mentioning a few names under 'acknowledgements'.


> Since the motivation relies on extremely heavy use of OOP, maybe
> discuss how prevalent this is and alternatives to that heavy use of OOP.


Isn't OOP to C++ kind of like bouncing a ball to basketball? Honestly
when I talk about doing OOP in C++, I feel like I'm telling people
that I use my kettle for boiling water (i.e. obviously I use my kettle
for boiling water).


> More discussion of alternatives and implementation would be useful. Discussion
> of alternatives could be done better by discussing each alternative as you present
> them instead of just listing a handful of points after. The design considerations section
> merely lists design choices without discussion or consideration.


I could have spent days and weeks more on it, but today I decided to
wrap it up as I'm going away on holidays on Friday.

I can in the future though give more thorough descriptions for each
individual example, and I probably will if I get an inkling that WG21
might actually nip at this.


> Please link a commit hash instead of a branch in case more commits are added at a later date.


That link is a GitHub tag. The tag is tagged onto the commit that adds
'chimeric_ptr' to the compiler.
I decided against having multiple branches because I can't expect
Matthew Godbolt to put half a dozen compilers up on his website for me
-- so instead, every time I change a feature like 'chimeric_ptr' or
'contains_mutable', I just rebase my trunk branch and re-tag the
commits. Matt's web server rebuilds my compiler at midnight every day.
By the way I wrote a Linux shell script that performs a rebase while
preserving tags:

    https://github.com/healytpk/gcc-thomas-healy/blob/trunk/rebase.sh


> Since the proposal is largely motivated by code size “ballooning” from templates,
> please discuss how significant this issue really is and discuss ICF.


I google'ed ICF just now and it came back with a few matching acronyms
-- which one do you mean?
My main objection to templates is that they prevent having an array of
function pointers, for example if you have an observer or perhaps a
list of delegates.


> Regarding forbid_ambiguity: Why is this not the default?


I want the default mode to be the most versatile. I'm always about
keeping a feature as versatile as possible. Take Duff's Device for
example:

void send( short *to, short *from, int count )
{
    int n = (count + 7) / 8;
    switch (count % 8)
    {
    case 0: do { *to = *from++;
    case 7: *to = *from++;
    case 6: *to = *from++;
    case 5: *to = *from++;
    case 4: *to = *from++;
    case 3: *to = *from++;
    case 2: *to = *from++;
    case 1: *to = *from++;
            } while (--n > 0);
    }
}

The above code would not have been possible if a rule had been made
that a 'do' loop cannot be interwoven within the cases of a 'switch'
statement. Without this restriction, Duff exploited the versatility to
write his 'device'.

In default mode, I leave 'chimeric_ptr' as versatile as possible. If
people want restriction, I welcome them to use the options.


> Implementation discussion where you claim compiler support is required
> should definitely mention reflection, especially given papers that will hopefully
> extend reflection capabilities in C++29.


Forgot about this. I was thinking that either:
(a) Reflection isn't possible with chimeric_ptr
or:
(b) I'd have to spend some time clearly specifying what happens when
you try reflection on a chimeric_ptr


> If the committee is interested, the name will be bikeshed.
> It would be worth considering alternative names.


I'm open to having a naming party -- as well as a gender reveal with
pink/blue smoke. Gender reveal is necessary for German: der Bikeshed,
die Bikeshed, das Bikeshed. I fly there 2 or 3 times a year so I have
to get this right or I'll be a laughing stock . . . like Volkswagen
and their Beetle (der Kafer / die Kafer).


On Mon, Dec 8, 2025 at 8:00 PM Bjorn Reese wrote:
>
> Section 9 claims that this is a plain library extension, but section 7.1
> says that "compiler support is required" and section 8 that "p->name
> performs ordered lookup". So you are changing the language lookup rules
> for this particular type.


Hmmm.... I don't consider it to be a "core language change" given that
the special behaviour only applies to one standard library type, and
the special behaviour won't be seen in any user-defined classes. But I
realise I'm teetering at the boundary between "library change" and
"core library change".


> chimeric_ptr contains a tuple with N pointers of different types
> pointing to the same object. This means that the size of the smart
> pointer is likely too large to be passed to a function in a register,
> which means that it is not a zero-overhead solution compared to the
> alternatives.


In its unoptimised form, yes there will be 8 bytes for every interface
(i.e. one pointer on x86_64). I could add another option that forces
the use of dynamic_cast, restricting it to one pointer. Passing 2 or 3
or 4 pointers on x86_64 isn't a big deal as the first 6 go in
registers.