pointer check in unit tests

[Michael Stahl]

On 05.11.20 10:09, Michael Stahl wrote:
> On 03.11.20 10:21, Stephan Bergmann wrote:
>> On 03/11/2020 09:37, Miklos Vajna wrote:
>>> (If you see a case where a pointer is returned and it can't be ever
>>> nullptr, then we should fix the return type to a be reference. Caolan
>>> did lots of fixes like that recently.)
>>
>> That's up for debate.  For example, if a sufficiently large fraction 
>> of call sites wants a pointer, it can be awkward to change a 
>> function's return type from pointer to reference.  (And doing so 
>> without carefully auditing all call sites can silently introduce 
>> regressions.)
>>
>> T& is something rather different than T* plus "cannot be null".  Just 
>> as the C++ type system isn't capable of expressing the type "int, but 
>> never 42", it isn't capable of expressing the type "T*, but never 
>> nullptr".
> 
> on a related note, i've heard it claimed that you can have a "T&, but 
> can be null" type in modern C++, as 
> std::optional<std::reference_wrapper<T>>.
> 
> although with ergonomics like
> 
>      std::optional<std::reference_wrapper<Foo>> foo(...);
>      foo->get().member;
> 
> i'm not sure how seriously to take such claims.

oh! there's a proposal to overload operator.() - surely that can only 
improve the situation!

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4477.pdf