Also missing discussion of
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1950r2.html and
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p0201r6.html

On Mon, Jun 9, 2025 at 6:13 PM Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Mon, Jun 9, 2025 at 9:25 AM Frederick Virchanza Gotham via
> Std-Proposals <std-proposals_at_[hidden]> wrote:
> >
> > Paper attached to this email in HTML format. Hasn't been published yet.
> >
> > Link to this version:
> > http://virjacode.com/papers/polyhandle_unpublished000.htm
> >
> > Link to the latest version:
> > http://virjacode.com/papers/polyhandle.htm
>
> I find it interesting that this "proposal" spends over a dozen
> paragraphs on the minor question of "how would this be implemented",
> while the most important question of "is this actually useful" is hand
> waved away with "There are many situations where it is useful". Like,
> why would a reflection system care if a type-erased object is
> polymorphic? Come to think of it, why would something using reflection
> use a *type-erased pointer* at all?
>
> I mean, even std::any's proposal
> (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3804.html),
> which doesn't have the best motivation section, provided a cursory
> exploration of the design space in its problem domain. `any_view`
> (
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3411r0.html#motivation
> )
> has a much better motivation section which clearly and effectively
> lays out at least what the problem domain actually is, with code
> examples of how awkward such things can be without the feature.
>
> I find this interesting... but not surprising.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>