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

[Steven Schveighoffer]

"Don" wrote
> 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).

Hm... then we have to implement 2 functions where only one is now necessary. 
Most likely the second function just is a void shell of the other.

For instance, chaining references are quite often returned, but you don't 
always have to "store" or use them.  Now we have to double all the functions 
so you have void versions too?

I do like the idea though on allowing a void/nonvoid overload.  It would be 
a very simple to check for by the compiler.  Just don't force me to use the 
return value if it's not important to.

-Steve