[cfe-dev] C++11 reverse iterators (was C++11 is here)

[Kyle Sluder]

> On Mar 5, 2014, at 11:32 AM, Chris Lattner <sabre at nondot.org> wrote:
> 
> 
>> 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.

FWIW, over in ObjC land we’re used to -get… returning an interior pointer, and -copy… returning a copy.

As someone who is trying to learn the codebase by writing code against it (and admittedly wielding the dual weapons of an AppKit bias and very little C++ experience), I'd be happy to see get() methods return an interior pointer, copy() methods return a deep copy, and unprefixed methods return an object with value semantics (including iterators and the like).

I’m sure there’s a much better term for this than I’m aware of, but I feel more comfortable using a prefix like ‘get’ to imply the caller retains “semantic ownership”. One might argue that methods which act like member access should resemble mirror direct member access, but I think prefixing with ‘get’ acts explicitly states intent on the part of the class author. 

--Kyle Sluder
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140305/12963bb9/attachment.html>