<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 3, 2014 at 9:48 AM, Chris Lattner <span dir="ltr"><<a href="mailto:sabre@nondot.org" target="_blank">sabre@nondot.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class=""><blockquote type="cite"><div dir="ltr"><div class="gmail_extra">In the best case 'get' doesn't really add any meaning, and in the worst case it is actively misleading</div>
</div></blockquote><div><br></div></div><div>It's getting the range though, just like Function::getArgumentList() returns the argument list.</div></div></blockquote><div><br></div><div>I really disagree (and I disagree with getArgumentList for the same reason).</div>
<div><br></div><div>getFoo should return something with value semantics (even if its a const reference to delay the copy). setFoo should directly mutate something.</div><div><br></div><div>What we're really doing is making the equivalent of a "member-like accessor" method.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class=""><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra">For example, you might iterate over operands, and assign through the iterator to mutate them.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">Really, these operate as range-views over some sequence. It seems particularly easy to teach foo_begin(), foo_end() -> foos() as well.</div></div>
</blockquote></div></div><br><div>That's a very objective-c thing to do :-), they use the pattern foo() and setFoo() for the getter and setter, respectively (and the naming is baked into the property model).  I don't feel strongly against it, but we pretty consistently use the Java style 'get' prefix everywhere else.</div>
</blockquote></div><br>If we have a setFoo, then I'm with you we should have a value-semantic getFoo. But we have just plain "op_begin" and "op_end" and I think that makes sense to extend to a range adaptor "operands".</div>
</div>