<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Removed it in r186006, thanks to David & Chandler for the feedback.</div><br><div><div>On Jul 9, 2013, at 1:02 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 9, 2013 at 11:48 AM, Argyrios Kyrtzidis <span dir="ltr"><<a href="mailto:akyrtzi@gmail.com" target="_blank" class="cremed">akyrtzi@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb adM"><div class="im">>>> Alternatively, this code doesn't seem to have any uses inside the llvm<br>
>>> codebase (at least not clang, llvm, compiler-rt, libcxx - maybe in<br>
>>> lldb?) nor any tests. Should we just remove it instead? (I assume you<br>
>>> have a use-case, or you wouldn't've been motivated to update it - is<br>
>>> that use case somewhere in the llvm project (broadly, across all<br>
>>> subprojects) or out of tree?)<br>
>><br>
>> It is used out of tree.<br>
><br>
> It might be more suitable for it to live along with the code that's<br>
> consuming it, I'd imagine. (that'd be my preference, at least - though<br>
> if it's really necessary for it to be here, it should probably at<br>
> least have unit tests)<br>
<br>
</div></div>Unit tests for this are overkill IMO, we could just start using it in new llvm/clang APIs.</blockquote></div><br>I think one of two things need to happen here:</div><div class="gmail_extra"><br></div><div class="gmail_extra">
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</div><div class="gmail_extra">2) We make a conscious decision to consistently recommend the use of this type as part of APIs in LLVM, Clang, and other projects.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">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).</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">My 2 cents.</div><div class="gmail_extra">-Chandler</div></div>
</blockquote></div><br></body></html>