The point of a method is to interact with an object.
A nullptr cannot be an object.
Can anyone cite a programing principle in which you would want to interact with an object that is not an object?
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Jonathan Wakely via Std-Proposals <std-proposals_at_[hidden]>
Sent: Thursday, October 31, 2024 2:06:09 PM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Jonathan Wakely <cxx_at_[hidden]>
Subject: Re: [std-proposals] Calling methods on a nullptr



On Thu, 31 Oct 2024 at 12:06, Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> wrote:

There are all kind of monadic expressions for testing for a value or error:



https://en.cppreference.com/w/cpp/utility/optional/value_or

https://en.cppreference.com/w/cpp/utility/optional/or_else

https://en.cppreference.com/w/cpp/utility/optional/and_then

https://en.cppreference.com/w/cpp/utility/optional/transform



https://en.cppreference.com/w/cpp/utility/expected/value_or

https://en.cppreference.com/w/cpp/utility/expected/or_else

https://en.cppreference.com/w/cpp/utility/expected/and_then

https://en.cppreference.com/w/cpp/utility/expected/transform

https://en.cppreference.com/w/cpp/utility/expected/transform_error



Also there is a proposal for operator?? renamed try?

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2561r2.html

Because baking that behaviour into the class so that the null check happens *after* dereferencing the pointer is the wrong place to do it, and is less flexible.