<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On May 26, 2014, at 5: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 Mon, May 26, 2014 at 4:43 PM, Andrew Trick <span dir="ltr"><<a href="mailto:atrick@apple.com" target="_blank">atrick@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto;"><div id=":4aa" class="a3s" style="overflow:hidden">This has been discussed before but I can’t find a reference to it. I could have sworn this was in the coding convention at some point. Here’s what I remember: during early LLVM development there was an effort to establish the convention that you described above—use pointer types only when nullptr is valid. This led to a lot of redundant declarations and annoying taking of addresses and dereferences. It turns out that the convention doesn’t really help for most informal/internal APIs. It’s actually no harder to debug a SIGSEGV than a nullptr check. I also adhered to this convention in a previous project and it never paid off.<br>
<br>
Once you begin working on a piece of code you get a feel for which types should be passed as pointers and which should be passed as reference. Then you try to pass types consistently regardless of whether a null input is valid. For example, some types, like the current context, should never be copied or passed by value and are obviously not null. That’s lower overhead in practice forcing callers to convert to a reference whenever we want to skip a null check.</div></blockquote></div></div></div></blockquote><div><br></div><div>This last sentence should read: it’s lower mental overhead for the programmer to use the same type consistently rather than worrying about another convention to follow at every call.</div><div><br></div><div>I would personally be happy to follow the pointer may be nullptr convention if it were used consistently. I was just trying to reiterate arguments against it that I’d seen w.r.t LLVM codebase, and I don’t see much value in forcing the convention everywhere.</div><div><br></div><div>-Andy</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto;">
</blockquote></div>FWIW, I disagree.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I much prefer to pass by reference unless there is the expectation of null inputs. I have never really agreed with the complaints about taking the address and have never found it to be a burden. I also find the simplicity of a consistent rule far more appealing than "getting a feel for which types" should be passed as pointers.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Ironically, using a reference can result in better optimizations by deleting redundant null checks. While I certainly hope this isn't relevant to the performance of LLVM, it's still not something to completely disregard.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Anyways, I've never really seen this become a problem in practice. I'm pretty happy for folks to use whatever local conventions they want. I'm usually happy to switch from reference to pointer if I'm hacking some part of the codebase I don't usually touch and one of the maintainers really prefers one over the other. It's not a big deal either way.</div>
</div>
</blockquote></div><br><div><br></div></body></html>