[llvm] r185851 - [ADT/NullablePtr] Allow implicit conversion of NullablePtr<OtherT> -> NullablePtr<T> if OtherT is derived from T.

Chandler Carruth chandlerc at google.com
Tue Jul 9 13:02:34 PDT 2013


On Tue, Jul 9, 2013 at 11:48 AM, Argyrios Kyrtzidis <akyrtzi at gmail.com>wrote:

> >>> Alternatively, this code doesn't seem to have any uses inside the llvm
> >>> codebase (at least not clang, llvm, compiler-rt, libcxx - maybe in
> >>> lldb?) nor any tests. Should we just remove it instead? (I assume you
> >>> have a use-case, or you wouldn't've been motivated to update it - is
> >>> that use case somewhere in the llvm project (broadly, across all
> >>> subprojects) or out of tree?)
> >>
> >> It is used out of tree.
> >
> > It might be more suitable for it to live along with the code that's
> > consuming it, I'd imagine. (that'd be my preference, at least - though
> > if it's really necessary for it to be here, it should probably at
> > least have unit tests)
>
> Unit tests for this are overkill IMO, we could just start using it in new
> llvm/clang APIs.


I think one of two things need to happen here:

1) We move this code to live with the out-of-tree consumers so that the
open source project isn't maintaining and carrying forward untested and
unused code paths, or
2) We make a conscious decision to consistently recommend the use of this
type as part of APIs in LLVM, Clang, and other projects.

As to why I would prefer #1 over #2: I don't (yet) buy the utility of this.
Instead, I prefer the simple rule: pointers are nullable, references are
not, and to use them for those purposes.

Yes, there is a challenge of re-binding a never-null pointer member of a
class, but the fact that this utility for addressing that problem has
gotten so little adoption makes me feel that this isn't a big problem, and
we already have sufficient tools to address it (such as assert()s around
mutation operations).

My 2 cents.
-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130709/55ef46cd/attachment.html>


More information about the llvm-commits mailing list