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
_______________________________________________
LibreOffice mailing list
LibreOffice@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/libreoffice
