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

[Argyrios Kyrtzidis]

Removed it in r186006, thanks to David & Chandler for the feedback.

On Jul 9, 2013, at 1:02 PM, Chandler Carruth <chandlerc at google.com> wrote:

> 
> 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/20130710/21996b99/attachment.html>