Date: Mon, 21 Sep 2026 20:07:04 +0200
With proper OOP there is a lot less necessity for downcasting than upcasting. Really, you can write most OO code without any downcasts. But it is nearly impossible to write OO code without any upcast. In this sense it is good that downcasts don’t have good ergonomics because a downcast is most likely the result of a bad design. We should make the wrong things hard and the right things easy.
Though, to be more specific: we want implicit upcasts only for pointers and references, not for the type itself.
On Sep 21, 2026, at 2:16 PM, Liam Graham <liamgraham_at_[hidden]> wrote:
Well then, it would be tedious to write the same for downcasting! Ergonomics!
Sent from Outlook for iOS
From: Simon Schröder <dr.simon.schroeder_at_[hidden]>
Sent: Monday, 21 September 2026 10:49:24
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Peter Bindels <dascandy_at_[hidden]>; Liam Graham <liamgraham_at_[hidden]>
Subject: Re: [std-proposals] Std-Proposals Digest, Vol 90, Issue 27Upcasting is necessary for proper object-oriented programming. It's the Liskov substitution principle. It would be quite tedious to write OO code if implicit casting wouldn't be allowed in this specific case.
On Mon, Sep 21, 2026 at 9:34 AM Liam Graham via Std-Proposals <std-proposals_at_[hidden]> wrote:
--it’s all about ergonomics. Yes type safety going X * to void * fine on paper because you’re throwing away information but in C++ void * and X * are considered different types. void is a different base type than X is. Reflect the type change by allowing explicit casting, not this weird half way implicit casting process. If you want type safety, C++ should reject implicit casting altogether, recognise both are different types and force the programmer to explicitly recognise and acknowledge the type change.
Sent from Outlook for iOS
From: Peter Bindels <dascandy_at_[hidden]>
Sent: Monday, 21 September 2026 08:30:46
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Liam Graham <liamgraham_at_[hidden]>
Subject: Re: [std-proposals] Std-Proposals Digest, Vol 90, Issue 27
On Mon, Sep 21, 2026 at 9:22 AM Liam Graham via Std-Proposals <std-proposals_at_[hidden]> wrote:
extra clarification: I understand type safety, but my position is about developer ergonomics.
Why are we allowing X * to void * rather than making the developer cast? While void * to X * is somehow requiring the developer to cast? Double standards isn’t it? If you’re worried about type safety you would enforce explicit casting for both since both are different types!
You either allow implicit conversion for both ends, or enforce explicit conversion for both ends. The double standards just confuses people!
No such thing. Converting from a typed pointer to an untyped one is a conversion to a less capable more generic type, which is equivalent to upcasting to an unknown base class. Upcasts are always ok if the base class is correct - and in this case we have a "base class" of zero information, so it's literally always fine.
Downcasting always requires a cast of sorts, whether from a T* to a U* or from a void* to a U*. There's zero information to know that converting from a T* or a void* to a U* is valid, so we need to have some force to make it do that cast anyway, or a dynamic_cast if both T and U are polymorphic types for a checked cast.
You need to re-read how type safety works. Your "double standards" reply does not reflect understanding of basic narrowing and widening concepts.
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2026-09-21 18:07:21