Date: Mon, 9 Jun 2025 20:43:02 +0200
> 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?
+1
When I read this proposal, I was dying to know what it's actually used
for. There are no concrete issues presented that this proposal clearly
solves, and there are no motivating examples which demonstrate how
this feature is beneficial. There are no performance or codgen
comparisons to some kind of status quo.
I mean, cool, we've got an implementation for std::polyhandle now.
Let's standardize it. Maybe we'll even come up with a use case at some
point, but we can always do that later :)
The paper structure is also bizarre and heavily deviates from the
template in https://isocpp.org/std/submit-a-proposal All that
implementation stuff could really be moved into a separate repository,
or it should be an appendix in the paper. The list of "Use cases"
should be in the Motivation section, not somewhere at the end of the
paper. There also needn't be a Conclusion to a proposal. The
Properties section should be in the Introduction.
> 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?
+1
When I read this proposal, I was dying to know what it's actually used
for. There are no concrete issues presented that this proposal clearly
solves, and there are no motivating examples which demonstrate how
this feature is beneficial. There are no performance or codgen
comparisons to some kind of status quo.
I mean, cool, we've got an implementation for std::polyhandle now.
Let's standardize it. Maybe we'll even come up with a use case at some
point, but we can always do that later :)
The paper structure is also bizarre and heavily deviates from the
template in https://isocpp.org/std/submit-a-proposal All that
implementation stuff could really be moved into a separate repository,
or it should be an appendix in the paper. The list of "Use cases"
should be in the Motivation section, not somewhere at the end of the
paper. There also needn't be a Conclusion to a proposal. The
Properties section should be in the Introduction.
Received on 2025-06-09 18:43:16