On Tuesday, 25 November 2025 16:04:30 Pacific Standard Time Frederick Virchanza
Gotham via Std-Proposals wrote:
> On Tue, Nov 25, 2025 at 5:32 PM Oliver Hunt wrote:
> > Another strategy to do what? You have yet to say.
>
> The original paper I shared, as well as the link to Arthur's blog,
> shows what the aim is. Here's that original post again:
>
> https://lists.isocpp.org/std-proposals/2025/11/15942.php

Then *write a paper* that explains the problem, how people work with this API
design flaw (or pitfall), what the solution should do (not *how* it does), and
what other alternatives there are. One alternative to investigate is "do
nothing, this only happens with poorly-designed APIs".

For your preferred solution, explain why it should or must be in the Standard.
It *must* be in the Standard if there's no way for a third-party library
solution to implement it (your hacks don't count). If it is possible to
cleanly implement in third-party, make an assessment of how often this problem
exists and needs to be solved.

> You're right. I intend to put a paper together showing not only the
> proposed feature (i.e. std::chimeric_ptr), but also a few
> alternatives.

There you go.

> I'm giving people the chance to interject with ideas at an early stage.

How? There is no paper to have a discussion on. Especially not one with an
explanation of how widespread the problem is and alternatives.

Arthur's blog post does not (always) indicate there is a problem to be solved.
Very often he highlights esoteric things that affect a handful of people on the
planet, but he thought would be interesting for the audience. Raymond Chen
does that too on his blog, and most of what he posts are not things that need
new solutions for.

> In my last email, I shared a GodBolt for the Itanium ABI x86_64 which
> was specific to the classes Colorful and Text, and it needed my
> customised compiler. Just now I've taken that code and made it
> generic, and also it works with unaltered GNU g++ trunk:

We DO NOT CARE about the implementation. The most that you need to do is prove
that it is possible, without breaking ABIs. The actual implementation, if
implemented by the Standard Library, can use compiler-provided support to do
it cleanly.

You may use the attempt at implementing it to prove that it must be in the
Standard Library, as I said above.

Other than those two cases, you're putting the card ahead of the oxen.

> struct Placard : Colorful, Text {
> Placard(void) : Text(666) {}
> void set_color(void) noexcept override { puts("Placard SetColor"); }
> void set_text (void) noexcept override { puts("Placard SetText" ); }
> };
>
> struct Billboard : Text, Colorful {
> Billboard(void) : Text(666) {}
> void set_color(void) noexcept override { puts("Billboard SetColor"); }
> void set_text (void) noexcept override { puts("Billboard SetText" ); }
> };

You should also explain why people make this mistake and how we could teach
them not to ("always sort your bases alphabetically" or "always use virtual
bases" or whatever). Alternatively, how the library that made this pitfall
could have avoided it.

iostreams also uses diamond-shaped polymorphism and virtual bases. How has it
avoided this problem?

The problem here is the mistake. The proposal is a way to work around the
problem, not fix it.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel Data Center - Platform & Sys. Eng.