Let's do front, back, popFront, and popBack!

[Don]

Andrei Alexandrescu wrote:
> Michel Fortin wrote:
>> On 2009-01-29 22:02:07 -0500, Andrei Alexandrescu 
>> <SeeWebsiteForEmail at erdani.org> said:
>>
>>> Steven Schveighoffer wrote:
>>>> Will popFront and popBack return the element removed?  Usually that 
>>>> is the meaning of pop (but not always).
>>>
>>> Great question. In STL they can't because C++ couldn't move values 
>>> reliably at the time (C++0X still can't IMHO but that's another 
>>> discussion). D would be able to because it has good support for 
>>> moving. I just don't want inefficiencies; returning e.g. a large 
>>> struct will still involve some memcpying even if costly resources are 
>>> not duplicated.
>>>
>>> So I'm ambivalent about this.
>>
>> That would seem like another good use for return type overloading:
>>
>>     void popFront();
>>     ElementType popFront();
>>
>> Too bad we can't have that.
>>
> 
> I've been thinking for a while to suggest Walter to allow overloading of 
> void vs. anything else return type. Making one private or undefined 
> would prevent statically that people call functions and ignore error codes.

That's a really interesting idea. You could force ownership, too, 
couldn't you? (So that you couldn't eg createFile("xxx") and forget to 
store the file handle).