<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sun, Sep 25, 2016 at 12:53 PM Chris Lattner <<a href="mailto:clattner@apple.com">clattner@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Sep 25, 2016, at 6:10 AM, Zachary Turner via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="gmail_msg" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:</div><div class="gmail_msg"><div dir="ltr" class="gmail_msg"><div class="gmail_msg">With that out of the way, here are some reasons I can see to allow StringRef accept null to its constructor which are independent of LLDB and stand on their own merit.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">1) std::string_view<> can be constructed with null.  I don't know when we will be able to use std::string_view<>, but there's a chance that at some point in the future we may wish to remove StringRef in favor of string_view.  That day isn't soon, but in any case, it will be easier if our assumptions are the same.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">2) [nullptr, nullptr+0) is a valid range.  Why shouldn't we be able to construct a StringRef from an otherwise perfectly valid range?</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">3) StringRef() can <b class="gmail_msg">already</b> be constructed from nullptr (!)  Surprised?  That's what happens when you invoke the default constructor.  It happily initializes the internal Data with null.  So why not allow the same behavior when invoking the const char * constructor?</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Thoughts?</div></div></div></blockquote><br class="gmail_msg"></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg">Seems fine to me, I think the default constructor behavior makes it clear that this is fine.  I don’t recall why the assert was originally added, but I don’t think it has added much (if any) value over the years.</div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">-Chris</div></div></blockquote><div><br></div><div> I just noticed it's not just the default constructor.  Even the const char*, size_t constructor allows null as long as you specify a 0 length.</div><div><br></div><div><div>    LLVM_ATTRIBUTE_ALWAYS_INLINE</div><div>    /*implicit*/ StringRef(const char *data, size_t length)</div><div>      : Data(data), Length(length) {</div><div>        assert((data || length == 0) &&</div><div>        "StringRef cannot be built from a NULL argument with non-null length");</div><div>      }</div></div><div><br></div><div>It seems that the only benefit of the asserting constructor is that it saves a branch when invoked with a character pointer (I would expect the branch to be optimized away when constructed with a string literal or char array).</div></div></div>