[llvm] r206372 - [Allocator] Make BumpPtrAllocator movable and move assignable.

[Duncan P. N. Exon Smith]

On 2014 Apr 18, at 13:59, David Blaikie <dblaikie at gmail.com> wrote:

> On Fri, Apr 18, 2014 at 1:43 PM, Chandler Carruth <chandlerc at gmail.com> wrote:
>> 
>> On Thu, Apr 17, 2014 at 7:04 AM, Duncan Exon Smith <dexonsmith at apple.com>
>> wrote:
>>> 
>>> The existence of a move constructor without a corresponding explicit copy
>>> constructor seems sufficiently explicit of a marker for "move only" to me.
>>> 
>>> 
>>> I think it looks more like an accident, not a marker.
>>> 
>>> I prefer Stroustrup's advice [1] on this.  It's not practical to follow
>>> all the time in this project because of MSVC support (no sense explicitly
>>> defining a default definition move constructor by hand if it's not going to
>>> be used anyway), but the style still makes sense to me when it's possible.
>>> It's cheap, and makes it clear that the omission is intentional.
>>> 
>>> [1]: http://www.stroustrup.com/C++11FAQ.html#default2
>>> 
>>> Do you disagree strongly?
>> 
>> 
>> I dunno about strongly, but it feels all wrong to me.
>> 
>> It feels like needless boilerplate, and I have a real allergy to
>> boilerplate. I suppose my real fear is that if programmers were to follow
>> this pattern consistently it would become a burden. At that point, they will
>> just stamp out the boiler plate using a macro or a some template in an IDE
>> or whatever, and they still won't think about it so we won't have solved
>> anything.
>> 
>> My preference is rule of zero, and minimally adding the routines you need.
>> This trusts the language to always DTRT when you add the subset, but I think
>> the language gets this right here.
>> 
>> /me continues to ponder.
> 
> FWIW I agree with Chandler here - by only implementing the minimal set
> of members needed and trusting the language/compiler to do the right
> thing we're in a better place.
> 
> Boilerplate is not not just visual noise for readers but can actually
> hurt us: should a type one day become copyable (when it was previously
> movable) then all types that have it as a member would need to be
> updated.

This is compelling.

Nevertheless, I bet many developers would be surprised that a patch
deleting a move constructor implicitly adds a copy constructor.

> Though I agree that it takes some effort to kick the "Rule of 3(5)"
> habit and trust the compiler - but we can all help each other to get
> there.

We're not just trusting the compiler; we're also trusting the (imperfect)
knowledge of developers.  I think the "rule of 5" is about making the
otherwise murky details of an API clear to current and future developers.

I'll think about this some more though.