Changing the return type of the containers' member functiuons resize and reserve.

[Vlad from Moscow]

I do not see a reason why the methods resize and reserve of standard containers have the return type void. In my opinion it would be much better if they would return a reference to themselves. Such a change will not influence on the existed code base.

[Gašper Ažman]

There is a school of thought that mutators should return void, because there is no way to confuse them with things that return a changed copy without changing the original.

On Fri, Jun 1, 2018 at 3:18 PM, 'Vlad from Moscow' via ISO C++ Standard - Future Proposals <std-pr...@isocpp.org> wrote:

I do not see a reason why the methods resize and reserve of standard containers have the return type void. In my opinion it would be much better if they would return a reference to themselves. Such a change will not influence on the existed code base.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/01f927fa-9176-44fa-b0a3-e17482f9996b%40isocpp.org.

[Richard Hodges]

When I first read the suggestion I was sceptical.

On Fri, 1 Jun 2018 at 16:51, Gašper Ažman <gasper...@gmail.com> wrote:

There is a school of thought that mutators should return void, because there is no way to confuse them with things that return a changed copy without changing the original.

If they didn't return void, what would be best for calling mutators on rvalues? Presumably this?

auto resize(size_t n) & -> vector&;

auto resize(size_t n) && -> vector&&;

This would allow code such as:

auto v = std::vector<int>().reserve(20);

Which is actually quite expressive, and starts to persuade me.

On Fri, Jun 1, 2018 at 3:18 PM, 'Vlad from Moscow' via ISO C++ Standard - Future Proposals <std-pr...@isocpp.org> wrote:

I do not see a reason why the methods resize and reserve of standard containers have the return type void. In my opinion it would be much better if they would return a reference to themselves. Such a change will not influence on the existed code base.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.

To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.

To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/01f927fa-9176-44fa-b0a3-e17482f9996b%40isocpp.org.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.

To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.

To post to this group, send email to std-pr...@isocpp.org.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkWUGAOfvhiae4FrBm15%2BbjQr9Yw_jdfDTMVdjEnmO0-9g%40mail.gmail.com.

[Nicol Bolas]

On Friday, June 1, 2018 at 12:18:45 PM UTC-4, Richard Hodges wrote:

When I first read the suggestion I was sceptical.

On Fri, 1 Jun 2018 at 16:51, Gašper Ažman <gasper...@gmail.com> wrote:

There is a school of thought that mutators should return void, because there is no way to confuse them with things that return a changed copy without changing the original.

If they didn't return void, what would be best for calling mutators on rvalues? Presumably this?

auto resize(size_t n) & -> vector&;

auto resize(size_t n) && -> vector&&;

This would allow code such as:

auto v = std::vector<int>().reserve(20);

Which is actually quite expressive, and starts to persuade me.

That's not a good argument for `resize`, since we already have matching sizing constructors. What we ought to have is a reserving constructor for `vector`.

I'm concerned about how this would increase the number of overloads for these functions. `resize` in particular already has 2 overloads; your suggestion would now require 4.

[Richard Hodges]

I share your concern. In the main I prefer free functions TBH. The standard seems shy of them on the whole.

 

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ffea28da-3c21-4966-bd18-0cbdf813d842%40isocpp.org.

[Nicolas Lesser]

I don't know a lot about ABI compatibility, but doesn't that break the ABI? Especially for implementations like MSVC that mangle the return type?

On Fri, Jun 1, 2018 at 4:18 PM 'Vlad from Moscow' via ISO C++ Standard - Future Proposals <std-pr...@isocpp.org> wrote:

I do not see a reason why the methods resize and reserve of standard containers have the return type void. In my opinion it would be much better if they would return a reference to themselves. Such a change will not influence on the existed code base.

--

You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/01f927fa-9176-44fa-b0a3-e17482f9996b%40isocpp.org.

[Arthur O'Dwyer]

On Friday, June 1, 2018 at 9:18:45 AM UTC-7, Richard Hodges wrote:

When I first read the suggestion I was sceptical.

On Fri, 1 Jun 2018 at 16:51, Gašper Ažman <gasper...@gmail.com> wrote:

There is a school of thought that mutators should return void, because there is no way to confuse them with things that return a changed copy without changing the original.

If they didn't return void, what would be best for calling mutators on rvalues? Presumably this?

auto resize(size_t n) & -> vector&;

auto resize(size_t n) && -> vector&&;

This would allow code such as:

auto v = std::vector<int>().reserve(20);

Which is actually quite expressive, and starts to persuade me.

I think you mean

    auto resize(size_t n) && -> vector;

because otherwise you've just disabled copy elision.

Anyway, yeah, you're basically doubling the number of methods in `vector` and introducing yet another overload resolution, for zero actual gain in codegen.

If `resize()` were going to return anything, it should return the old value of end(), and/or, a boolean indicator of whether reallocation happened. Returning the `this` pointer (which the caller already has in a register by definition) is just wasteful.

So, let's not do this.

–Arthur

[Nicol Bolas]

On Friday, June 1, 2018 at 6:33:37 PM UTC-4, Arthur O'Dwyer wrote:

On Friday, June 1, 2018 at 9:18:45 AM UTC-7, Richard Hodges wrote:

When I first read the suggestion I was sceptical.

On Fri, 1 Jun 2018 at 16:51, Gašper Ažman <gasper...@gmail.com> wrote:

There is a school of thought that mutators should return void, because there is no way to confuse them with things that return a changed copy without changing the original.

If they didn't return void, what would be best for calling mutators on rvalues? Presumably this?

auto resize(size_t n) & -> vector&;

auto resize(size_t n) && -> vector&&;

This would allow code such as:

auto v = std::vector<int>().reserve(20);

Which is actually quite expressive, and starts to persuade me.

I think you mean

    auto resize(size_t n) && -> vector;

because otherwise you've just disabled copy elision.

You can't have elision in this case no matter what. Doing `std::vector<int>().reset` will manifest a temporary. You can't elide that temporary; the standard requires it to exist. `reset` will be given a `this` pointer to that temporary.

If it returns an rvalue-reference to `*this`, then the eventual assignment will move from the temporary to the destination.

If it returns a prvalue, that prvalue can only be generated by taking *this and moving it into a stack object, right? Well, that move into the stack object from *this can't be elided. Even if you did something like `return vector<int>(std::move(*this))`, that cannot elide the move from `*this` to the prvalue.

So it's best to just return the rvalue reference. It's a common idiom for this sort of thing.

[Victor Dyachenko]

On Friday, June 1, 2018 at 5:18:47 PM UTC+3, Vlad from Moscow wrote:

I do not see a reason why the methods resize and reserve of standard containers have the return type void. In my opinion it would be much better if they would return a reference to themselves.

Or size() and capacity() respectively?