On Tue, May 9, 2017 at 12:58 PM, Emilio Cobos Álvarez <emi...@crisal.io> wrote: > I think references help to encode that a bit more in the type system, > and help reasoning about the code without having to look at the > implementation of the function you're calling into, or without having to > rely on the callers to know that you expect a non-null argument. > > Personally, I don't think that the fact that they're not used as much as > they could/should is a good argument to prevent their usage, but I don't > know what's the general opinion on that.
The relevant bit of the Core Guidelines is https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rf-ptr-ref and says: "A pointer (T*) can be a nullptr and a reference (T&) cannot, there is no valid "null reference". Sometimes having nullptr as an alternative to indicated "no object" is useful, but if it is not, a reference is notationally simpler and might yield better code." As a result, I have an in-flight patch that takes T& instead of NotNull<T*> where applicable, even though I do use NotNull<T*> to annotate return values. I agree that in principle it makes sense to use the type system instead of relying on partial debug-build run-time measures to denote non-null arguments when possible. That said, having to dereference a smart pointer with prefix * in order to pass its referent to a method that takes a T& argument feels a bit odd when one is logically thinking of passing a pointer still, but then, again, &*foo seems like common pattern on the Rust side of FFI to make a reference out of a pointer and effectively asserting to the human reader that the pointer is null. -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
