<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 5, 2013 at 6:08 PM, Nick Lewycky <span dir="ltr"><<a href="mailto:nicholas@mxc.ca" target="_blank" class="cremed">nicholas@mxc.ca</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":7i5" style="overflow:hidden">Chandler Carruth wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
On Fri, Jul 5, 2013 at 5:29 PM, Nick Lewycky <<a href="mailto:nicholas@mxc.ca" target="_blank" class="cremed">nicholas@mxc.ca</a><br></div><div><div class="im">
<mailto:<a href="mailto:nicholas@mxc.ca" target="_blank" class="cremed">nicholas@mxc.ca</a>>> wrote:<br>
<br>
    +  bool onlyReadsMemory(unsigned n) const {<br>
    +    return AttributeSets.hasAttribute(n, Attribute::ReadOnly) ||<br>
    +           AttributeSets.hasAttribute(n, Attribute::ReadNone);<br>
    +  }<br>
    +  void setOnlyReadsMemory(unsigned n) {<br>
    +    addAttribute(n, Attribute::ReadOnly);<br>
    +  }<br>
    +<br>
<br>
<br>
It seems weird interface wise to only expose this in the 'or' form. I<br>
know the only user you have today expects that form, but interface wise<br>
it would seem cleaner to either expose the attribute semantics directly,<br>
or to expose an OR of the attributes and the readnone separately (as<br>
readnone is essentially a strict subset of readonly).<br>
</div></div></blockquote>
<br>
This is how the readnone/readonly function attributes already worked, I just added 'parameter n' variants. I can't think of any clients who are interested in seeing that something is readonly-but-not-readnone.</div>
</blockquote></div><br>Sure, I'm mostly asking why no accessors on Function for readnone? Note that CallSite has an additional accessor. I would either get rid of the one on CallSite or add one here.</div></div>