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

[bearophile]

Andrei Alexandrescu:
> I just don't want inefficiencies; returning e.g. a large struct will 
> still involve some memcpying even if costly resources are not duplicated.

If a larger and more complex API can be tolerated, then you can add a method to remove the last/first item without returning it (so the pop methods return it).

To append items you can use tilte-equal operator, and to prepend you may use the ".prepend(...)" method.

Another silly possibility is, inside the pop methods, identify in some way the code that returns the value, and don't compile it. So the compiler is able to almost automatically create two return-overloaded functions, one that returns and one that doesn't return. To do this the programmer may add some tag, or the compiler may do it automatically, removing the "return" from a second version of the function, and then removing dead code that created the data that is given by the return.


>Making one private or undefined would prevent statically that people call functions and ignore error codes.<

I think this is an important enough thing; GCC too thinks it's important because it allows this function attribute:

warn_unused_result
    The warn_unused_result attribute causes a warning to be emitted if a caller of the function with this attribute does not use its return value. This is useful for functions where not checking the result is either a security problem or always a bug, such as realloc.

              int fn () __attribute__ ((warn_unused_result));
              int foo ()
              {
                if (fn () < 0) return -1;
                fn ();
                return 0;
              }

    results in warning on line 5

Bye,
bearophile