llvm dev - Mar 2014 - [LLVMdev] [cfe-dev] C++11 reverse iterators (was C++11 is here)

On Mar 3, 2014, at 10:29 AM, Chandler Carruth <chandlerc at google.com>
wrote:
> 
> On Mon, Mar 3, 2014 at 9:48 AM, Chris Lattner <sabre at nondot.org>
wrote:
>> In the best case 'get' doesn't really add any meaning, and
in the worst case it is actively misleading
> 
> It's getting the range though, just like Function::getArgumentList()
returns the argument list.
> 
> I really disagree (and I disagree with getArgumentList for the same
reason).
> 
> getFoo should return something with value semantics (even if its a const
reference to delay the copy). setFoo should directly mutate something.
> 
> What we're really doing is making the equivalent of a "member-like
accessor" method.
Ok, can this be generalized into guidance we can put in the coding standards?

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140303/2e0bb6ab/attachment.html>

On Mon, Mar 3, 2014 at 4:42 PM, Chris Lattner <sabre at nondot.org> wrote:
> Ok, can this be generalized into guidance we can put in the coding
> standards?

I mean, maybe. I'm not sure it comes up frequently enough to be worth space.

My off-the-cuff idea of how to say this in the guide would be:

"""
When providing getters and setters in APIs they should generally have value
semantics: the returned object from a getter should be immutable or a copy,
and arguments to the setter should be copied into the object. Naturally, if
the member is itself a pointer, this applies to the pointer and not the
pointee. If you are providing access to contained objects through some
transparent view like iterators, ranges, or adaptors these should have
reference semantics and be distinct from either a getter or a setter.
"""

But this isn't terribly satisfying to me as a rule. It's much easier to
talk in context about specific APIs than provide this level of guidance IMO.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140304/ab6dd1a3/attachment.html>

This rule does not seem to be widely followed by Clang today. Looking at
Parser and Sema, many getters (0 argument functions with names matching
/^get[A-Z]/) return mutable references to long-lived objects. Looking
through Decl.h, things are a little different: we rarely return references,
but do frequently return pointers that provide mutable access to contained
objects.


On Tue, Mar 4, 2014 at 5:49 PM, Chandler Carruth <chandlerc at
google.com>wrote:
>
> On Mon, Mar 3, 2014 at 4:42 PM, Chris Lattner <sabre at nondot.org>
wrote:
>
>> Ok, can this be generalized into guidance we can put in the coding
>> standards?
>
>
> I mean, maybe. I'm not sure it comes up frequently enough to be worth
> space.
>
> My off-the-cuff idea of how to say this in the guide would be:
>
> """
> When providing getters and setters in APIs they should generally have
> value semantics: the returned object from a getter should be immutable or a
> copy, and arguments to the setter should be copied into the object.
> Naturally, if the member is itself a pointer, this applies to the pointer
> and not the pointee. If you are providing access to contained objects
> through some transparent view like iterators, ranges, or adaptors these
> should have reference semantics and be distinct from either a getter or a
> setter.
> """
>
> But this isn't terribly satisfying to me as a rule. It's much
easier to
> talk in context about specific APIs than provide this level of guidance
IMO.
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140304/fb207a28/attachment.html>