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

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>

On Tue, Mar 4, 2014 at 6:06 PM, Richard Smith <richard at metafoo.co.uk>
wrote:
> 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.

Yea, but I *significantly* prefer the rules I describe. =]

The latter case is the one that is hard to write rules around. Sometimes,
you are notionally getting a reference or a pointer, and the mutability is
irrelevant. Other times, the reference or pointer present should not be
exposed through a getter.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140304/a5f3d7f4/attachment.html>

On Mar 4, 2014, at 6:14 PM, Chandler Carruth <chandlerc at google.com>
wrote:
> 
> On Tue, Mar 4, 2014 at 6:06 PM, Richard Smith <richard at
metafoo.co.uk> wrote:
> 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.
> 
> Yea, but I *significantly* prefer the rules I describe. =]
I don't think your rules are feasible.
> The latter case is the one that is hard to write rules around. Sometimes,
you are notionally getting a reference or a pointer, and the mutability is
irrelevant. Other times, the reference or pointer present should not be exposed
through a getter.
This is a nice blue sky ideal, and if efficiency didn't matter perhaps it
would work.  However, efficiency does matter, and our apis have all sorts of
"give me access to internal bits" APIs for a reason.  If you really
want to provide value semantics, you actually have to do a deep copy of anything
returned, at which point this whole thing becomes immediately unworkable.  For
example, we can't have Instruction::getOperand() or Instruction::getParent()
return something with true value semantics.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140305/20ce3625/attachment.html>