Hi Stephan, On Tue, Nov 03, 2020 at 10:21:34AM +0100, Stephan Bergmann <sbergman@xxxxxxxxxx> 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". Somehow I assumed that we always try to return std::unique_ptr<> for owning pointers and references for non-owning pointers (at least in new code), but perhaps that was too naive. :-) If a never-nullptr pointer is returned, it would be really useful to somehow state that in the function's signature. Are you aware of any way to do that? There is C's __attribute__((nonnull)), but it only works on function parameters, I think. Regards, Miklos _______________________________________________ LibreOffice mailing list LibreOffice@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/libreoffice