F.41 should suggest returning a struct, not a tuple

[andyprowl]

I think F.41 ("Prefer to return tuples to multiple out-parameters") should become "Prefer returning aggregate class types to multiple out-parameters" (or something like that, what I mean is "prefer returning a struct").

Structs have names and their fields have names, which helps understanding and reasoning about code. The variables used in std::tie() have names too, but the user needs to declare those names consistently and meaningfully at every point of use; this is error-prone. Also, those variables must be pre-declared, and two-step initialization is not idiomatic in C++ (and particularly ugly if default-construction is not an option).

Tuples might be a better option for certain kinds of generic code, but I don't see them as a candidate for a default guideline on returning multiple values.

[galik]

I think these are very valid points.

Tuples are not ideal interface companions. Returning a std::tuple to a std::tie feels like simulating a language ability to return multiple variables. It would be nice to have a little language support to make returning a struct simpler.

Something like this perhaps?

auto func() -> struct{ bool good; int i; std::string text; }
{
    return {true, 6, "yeehar"};
}

// ..

auto ret = func();

if(ret.good)
{
    // use ret.i and ret.text here ...    
}

I actually half expected that syntax to work already but I can't get the compiler to accept an anonymous struct as a trailing return type.

Also returning a struct rather than doing a std::tie facilitates RVO.

[germandiagogomez]

In D you can do this:

alias tup = tuple!(bool, "good", int, "i", string, "text");

I am jealous :( This needs at least string mixins and "universal parameters". There is a paper that mentions auto as any non-type parameter. I think we should have extensions to accept both kinds at some point, it is just more flexible.

[andyprowl]

I don't know D, but it seems to me this would only solve the two-phase initialization problem. The user still needs to declare those names at every point of use, with potential consequences in terms of consistency, readability, etc.

[gdr-at-ms]

Thankfully, there is a proposal in the work to allow structured binding.

[germandiagogomez]

Thankfully, there is a proposal in the work to allow structured binding.

Where could I find that?

[NicolBolas]

Here's a better idea than a tuple:why not return an anonymous struct:

auto func()
{
  struct { bool good; int i; std::string text; } var;

  return var;
}

OK, obviously you can't do this if the function isn't inline. But where convenient, a struct is much better than a tuple.

[NicolBolas]

It should also be noted that with P0144 (mentioned by Bjarne Stroustrup in his Kona report ), we may have the abiliity in C++17 to do this:

auto {x, y, z} = make_tuple(2, std::string("foo"), 5.4f);

This would obviously work with tuple return values too. Possibly with a user-defined mechanism to allow fetching from arbitrary user objects.

So tuple might be the better answer for ad-hoc multiple return values in the long run.

[andyprowl]

Personally I do not like this solution. Not to this problem at least. It would solve the issue with 2-phase initialization, but it would still require the caller to declare those names at every point of use, which might compromise consistency and readability. Also, reordering tuple members would require changing all points of call.

I'd much rather prefer the solution proposed by Galik earlier in this thread.

[germandiagogomez]

For me the conclusion is that we do not have a conclusion on this. Maybe there should be no strong guideline in this case.

[andyprowl]

What's wrong with "Prefer returning aggregate class types to multiple out-parameters"? The only disadvantage I see are the extra keystrokes required to define the return type (but that shouldn't be a huge concern, right?); from the viewpoint of readability and maintainability I don't see any major drawback.

[germandiagogomez]

What's wrong with "Prefer returning aggregate class types to multiple out-parameters"?

I am not if you say this cause of my last comment. What I meant, anyway, the tuple vs struct debate did not finish with a real conclusion. I did not mean the out parameters at all. But I am not sure you say this because of my last comment.

[galik]

I honestly don't see any benefits to returning a tuple rather than a struct. There maybe some corner-cases when you happen to have the right variable laying around, otherwise you have to define them individually and even then there is always room to std::tie the wrong variable.

With a struct you get to follow the always initialize a variable rule that using std::tie breaks.

struct func_ret_type { bool success; int i; };
func_ret_type func(); // maybe keep struct defn next to func prototype
// ...
func_ret_type ret = func(); // follows always initialize rule (ES.20)

// seems better than

bool success; // not initialized
int i; // not initialized
std::tie(success, i) = func(); // complex initialization frowned upon (ES.20)

// or worse

bool success; // not initialized
int i; // not initialized
std::tie(success, j) = func(); // whoops wrong variable

There is some discussion regarding the always initialize rule (ES.20) here: #131

[andyprowl]

@galik: Well, we were discussing the new proposal brought up by Nicol Bolas. Sure, std::tie and two-phase initialization are definitely not what I'd like to see in a guideline, but P0144 would solve this problem. The issue I see is that it does not solve the main problem - consistent naming, sensitivity to reordering of members, etc. Tuples are convenient when you want positional access. I just don't think you'd want that very often. IME it is a use case that comes up fairly frequently with generic code, but that's not enough to make it a default guideline.

@germandiagogomez: Yes, I wrote that because of your last comment. Personally I think there should be a strong guideline, and it should be "Prefer returning aggregate class types to multiple out-parameters".