> On Jun 9, 2025, at 3:17 PM, Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> On Mon, Jun 9, 2025 at 8:17 PM Thiago Macieira wrote:
>>
>> Several people told Frederick, repeatedly, that he was coming up with a
>> solution in search of a problem
>
>
>
> You're right, I'm working backwards on this one. In all the papers
> that I've submitted to Nevin to get a P number, I've put in
> motivations -- I wrote those papers describing a problem and then
> proposing a solution. I wouldn't submit this draft paper to Nevin
> without any clear motivations and code examples.
>
> The reason I'm working backwards on this one is that it's such a
> low-level facility.

You’re missing the point - if there’s a sufficiently compelling use case,
the language and supporting runtimes would simply be changed to
support the use case. There’s no need for a proof of concept implementation,
especially not one based on assumptions about implementation details.

What you need to do is provide the compelling use case to warrant
such a feature. Once you have the actual use cases we can discuss
whether there’s an existing solution to the problem, if the use cases
are actually sound, and then if they are, whether this is the best approach
to fixing it.

> With such basic functionality at such a low level,
> there's so many possibilities to find uses at mid and higher levels.

Then provide them.

> Like this: I've already shown that you can 'dynamic_cast' from a '
> void * ' to a ' void * ', so long as both the source and destination
> are polymorphic, but I want to take it a step further and try to
> 'dynamic_cast' from a ' void * ' to any polymorphic type. The idea
> being that if you have a polyhandle, then you can use a method called
> 'dynamicCast' to check if you can get any given polymorphic type from
> it, like this:
>
> SomePolymorphicClass obj;
> SomePolymorphicBase &b = obj;
> std::polyhandle p(b);
> auto *const ptr = p.dynamicCast< SomeOtherPolymorphicBase >();
>
> Looking at the Itanium ABI, 'dynamic_cast' is implemented as:
>
> void *_dynamic_cast (
> const void *src_ptr, // object started from
> const __class_type_info *src_type, // type of the
> starting object
> const __class_type_info *dst_type, // desired target type
> ptrdiff_t src2dst) // how src and dst are related
>
> And looking at the Microsoft ABI, 'dynamic_cast' is implemented as:
>
> void *__RTDynamicCast( void *inptr, long VfDelta, void *SrcType,
> void *TargetType, bool isReference );
>
> So I think I _might_ be able to get this to work on both ABI's. And if
> I do get this working, that's when it will really get interesting and
> open up all sorts of possibilities. I'll be able to come with loads of
> good examples. But even if it turns out that the 'dynamicCast' method
> won't work on both Itanium and Microsoft, I have a few other
> half-baked ideas about possibilites for std::polyhandle.

Not sure of the MS implementation, but in stdlibc++ and libc++
__dynamic_cast assumes that the source type_info and the object has
already been adjusted to support the path to the target type.

The functional result is that if you try to dynamic cast with a static type that
is a subtype of the target type, the cast can fail.

Again, in c++ a dynamic cast depends on the knowledge of the static type
of the type, and the relationship between the static type of the subject and
the target type. You don’t have access to that information, so you cannot
do this cast safely.

You also don’t know the correct offset flags for the calls, because you don’t
know the the static relationship between the source and target. I’m still not
sure the exact meaning of that parameter either (a few negative values are
signals or hints to the runtime at least).

The fundamental problem that you seem unwilling to understand that the
c++ type system does not have a polymorphic bottom type, and what you’re
doing is essentially trying to create one by hacking around assumptions in
the type system.

You do not need to do that, because quite simply if the standard were changed
to require the rtti system support this kind of thing, then the compiler and
runtimes would introduce the required functionality to support it. Doing that
would have costs, so the use cases would need to be sufficient to justify that
cost.

That’s why you need to provide the use cases. Not a solution in search of
use cases.

On the other hand, other people have pointed to prior communications in
which you have similarly refused to provide the use cases. You cannot at
this point claim you are not aware of this requirement, so what you’re doing
is acting in bad faith, and wasting everyone's time.

If you are still unwilling to provide use cases the warrant this feature, please
just stop posting. Step 1 of a proposal for any standard is the justification
for the feature, and if you cannot/will not do that you aren’t making a proposal
you're making noise.

My personal preference at this point is for you to stop sending emails, and
instead write an actual proposal. You can see many examples of proposals
that you can use to model you proposal on at https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025
(and prior years/meetings as well)

—Oliver

> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals