<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Aug 25, 2014 at 6:27 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class=""><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 25, 2014 at 6:05 PM, Sean Silva <span dir="ltr"><<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yes. It was in reply to a statement that seemed to suggest a "design public API up front, then implement the whole thing" approach (not a "incrementally approach our use cases, carefully considering the design of the API at each step" approach). It seems like the "design API up front" approach is the exception rather than the norm in LLVM-land, so it was strange to see it being suggested as a preference.</blockquote>

</div><br></div></div><div class="gmail_extra">Sorry, I wasn't trying to preclude an incremental approach here.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I'm saying design the API that you are adding, as you add it. That doesn't have to be the *entire* API or the final version of the API. Each increment should be designed with some care and thought behind it.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">The proposed patch is specifically not doing *any* design of the API or finding small increments at which the design makes sense.<br></div><div class="gmail_extra">

<br></div></div>
</blockquote></div><br></div><div class="gmail_extra">A similar design approach occurs for all API's, be they "internal" or not, as API cleanliness and usability is a boon for internal users as well as external.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Actually, we must have been doing a pretty good job about the API design from the fact that users have been able to hoist these headers into include/ and get good mileage from them, to the point that the requested change is simply to move them to include/.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">I agree that just slopping clang/lib/CodeGen/*.h file into include/ is not the right approach. However, I don't think there's an intrinsic reason to expect that the API's are somehow unsuitable for public use exactly as they stand now in lib/. I would prefer (modulo Richard's comment about not exposing these without internal users), that as we get compelling use cases, we bring up the necessary headers into include/ to satisfy them, making any necessary incremental changes to better serve the use case.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">-- Sean Silva</div></div>