Free functions std::back() and std::front()

[d.n.i...@gmail.com]

In C++, we have std::{c, r}begin/end(x), std::size(x) and std::empty(x) as a free functions, so we can get the appropriate things from an arbitrary collection;

But there aren't (and aren't proposed, as I know) std::back/front(x) functions with respective meanings. Isn't it a defect?

To clearly understand what I mean, consider the following code (for back() function):

template <class T, std::size_t Size>

decltype(auto) back (T (& array) [Size])

{

    return array[Size - 1];

}

template <class Container>

decltype(auto) back (Container & container)

{

    return container.back();

}

I think these functions might be very useful to clearly express the intention of getting the last/first value of a collection, the type of which may be either a container or an array.

[Nicol Bolas]

On Friday, February 12, 2016 at 7:12:19 AM UTC-5, d.n.i...@gmail.com wrote:

In C++, we have std::{c, r}begin/end(x), std::size(x) and std::empty(x) as a free functions,

No, we don't. The Ranges TS may eventually provide such entrypoints. But the only interfaces that C++14 has are `(c)begin/end`.
 

so we can get the appropriate things from an arbitrary collection;

Those interfaces are for getting iterators from containers/views, not from getting values/references from containers/views.
 

But there aren't (and aren't proposed, as I know) std::back/front(x) functions with respective meanings. Isn't it a defect?

Defects are generally:

1) The spec being self-contradictory.

2) The spec not specifying behavior for certain cases.

Something you think ought to be there which isn't is not a defect; it's a proposal.

Personally, I don't much care for the idea, since `back` and `front` can be emulated with `begin`/`end`.

[Ville Voutilainen]

On 12 February 2016 at 18:57, Nicol Bolas <jmck...@gmail.com> wrote:
> On Friday, February 12, 2016 at 7:12:19 AM UTC-5, d.n.i...@gmail.com wrote:
>>
>> In C++, we have std::{c, r}begin/end(x), std::size(x) and std::empty(x) as
>> a free functions,
>
>
> No, we don't. The Ranges TS may eventually provide such entrypoints. But the
> only interfaces that C++14 has are `(c)begin/end`.

Those functions are in the current C++ working draft. Unless someone
makes a good
case for removal, C++17 will have them. The libstdc++ that will come out with
gcc 6 will ship them.

>> But there aren't (and aren't proposed, as I know) std::back/front(x)
>> functions with respective meanings. Isn't it a defect?

No, that's an extension.

> Defects are generally:
> 1) The spec being self-contradictory.
> 2) The spec not specifying behavior for certain cases.

...and the spec being simply incorrect in other ways, but not for
lacking functionality
some user would really really want.

> Something you think ought to be there which isn't is not a defect; it's a
> proposal.

Exactly.

[T. C.]

https://issues.isocpp.org/show_bug.cgi?id=30

They were proposed in N4017 along with size()/data()/empty(); LEWG took them out. 

[rick...@hotmail.com]

As T.C. said, the LEWG requested that I remove front() and back() from the proposal. I think it was a little petty of the LEWG, especially when the straw poll was 6-4 in favour. I acquiesced because I thought size() and empty() were too important to risk a fight with the committee. 

It may be worth proposing again, I can't see any reference to front() and back() in the Ranges TS.