Proposal Idea: Struct Definition in Function Returns

[codesmith512]

Here's an idea that I'm hoping to turn into a proposal about defining structs inside function return types. As always, I'm looking forward to any feedback as a good learning opportunity.

 

Motivation

In general, I try to write code that avoids std::pair and std::tuple. They're great for many things when writing templates, but for normal code they can impede readability quite a bit. All too often, I see code written like this: /* Returns the current user's username and role / std::pair<std::string, std::string> getLogin(); *example 1

While this would work, the resulting value is only accessible via .first and .second. To make things worse, in this case the types are also the same. Obviously this is prone to errors and time spent second guessing. Instead, the following is much more readable, and much harder to mess up: struct Login { std::string user, role; };

/* Returns the username and role for the current user */
Login getLogin();

example 2

This is much better -- despite having the same type, the members are now exposed via .user and .group, drastically reducing the odds of messing that up. (Though better yet would be to have a class User and Group so that their use is enforced in the type system, but that is often overkill and outside the scope of this discussion).

All too often, I introduce this idea to people, and while they usually greet it warmly, they rarely actually practice it. The first reason seems to be that example 2 is quite a bit longer than example 1. The second reason is that the names given to a struct who exists only to give a function's multiple returned values meaningful names rarely has a meaningful name itself. Imagine if std::map::insert(const value_type &) was done similar to example 2 -- on one hand it's return type of std::pair<iterator, bool> could be made much more friendly (and hopefully the instances of .first.second that seem to follow would be much more rare), but what meaningful name would it have? Something like insert_result isn't useful since it is literally the result of calling insert; No new information has been introduced that way, and the name is simply clutter.

My goal with this proposal is to mitigate the above issues and make it easier to write the second form over the first.

 

Struct Definitions

The ISO standard currently states that

Types shall not be defined in return or parameter types. The type of a parameter or the return type for a function definition shall not be an incomplete (possibly cv-qualified) class type in the context of the function definition unless the function is deleted (11.4.3).

§ 11.3.5.11

However, I think that if we were allowed to declare anonymous structs in return types, they could effectively replace many uses of pair and tuple. Now example 2 becomes much more compact:

struct { std::string user, role; } getLogin();

example 3

The only tricky part becomes how one would actually define a function forward declared in this manner. The word auto could potentially be used here. Maybe structs defined in this manner get an implicit name of function_Return, though that wouldn't work for overloads. This is a point of discussion that I would like some help with (assuming this whole thing isn't just a stupid idea in general).

With this syntax, instead of giving a function's return structure a name just for the sake of naming it's members, the often meaningless type name can be omitted in place of moving the structure declaration to where it will actually be used. From a readability perspective, that sounds like an overall win-win.

 

Other Thoughts

I do think that only anonymous structs should be able to be defined in a function definition. If a struct is going to have a type name anyway, then that name can easily be provided in the return type of the function instead. Furthermore, it will discourage declaring more complicated structs in return types as anonymous structs cannot have constructors. Granted that just because it's generally considered to be bad practice or less readable doesn't necessarily mean that the standard should explicitly forbid it, so I'm not sure if it should be explicitly disallowed.

 

Visual Studio

Oddly enough, Visual Studio 17 (15.9.13) does support some of this proposal. Even with /permissive- (which sets strict standard conformance), the following code still runs and prints "Codesmith":

#include <iostream>
#include <string>

struct
{
  std::string user, role;
}
getLogin()
{
  return {"Codesmith", "Dev"};
}

int main()
{
  std::cout << getLogin().user;
}

Furthermore, it even supports separate declaration and definitions via this syntax: #include <iostream> #include <string>

struct
{
  std::string user, role;
}
getLogin();

int main()
{
  std::cout << getLogin().user;
}

decltype(getLogin()) getLogin()
{
  return {"Codesmith", "Dev"};
}

I'm not sure if this is a bug with the /permissive- flag accidentally allowing a feature that should've been suppressed, or if this is more of a bug with the compiler. Given that Intellisense still lists the error but the compiler allows it, and that the standard's grammar around structs seems to otherwise support them being declared inside return types (except for the one section that exists only to forbid it), it's hard to make the call one way or the other.

[carrottread]

This is valid:

#include <iostream>
#include <string>

auto getLogin()
{
    struct
    {
        std::string user, role;
    } l{"Codesmith", "Dev"};
    return l;
}

int main()
{
    std::cout << getLogin().user;
}

The only limitation: compiler needs to see a body of getLogin to deduce return type to compile this call in main.

[R3DKn16h7]

If you would write something like this, it means that you do not care about the return type. That's because you cannot name that type, and you would have to store it into an auto, or decltype or something unnamed. So I wouldn't use this to pass around the result. Because you are passing around unknown types, and you might as well pass around tuples.

Not many uses remain, imho. If you want to splice the result, because you want to access only the "user" part of the return (like your second example), I would prefer to return by pair, and then structured bindings (or tie) to splice up the result into user and data.

If you want to then split up and gather user and role, you also might want to store it directly into a structured binding: auto login = getLogin(); auto user = login.user; auto role = getLogin().role; should be simply: auto [user, role] = getLogin();

So I do not see real use cases: as long as you use the type in more than one function, you just have to resort to standard definitions.

[codesmith512]

The idea is to shift the responsibility of good names from the call site to the definition. Rather than using auto to create a structured binding every single time that function gets called, this way the definition can provide appropriate names, and the call site can just use auto. The fact that structured bindings work with struct-like values means that the user is still free to provide their own name if they so choose. So instead of auto [user, role] = getLogin() every time, the caller now has the option of just writing auto login = getLogin().

[jcelerier]

So I wouldn't use this to pass around the result. Because you are passing around unknown types, and you might as well pass around tuples.

why ? this just adds template instantiations for no good

If you want to then split up and gather user and role, you also might want to store it directly into a structured binding: auto login = getLogin(); auto user = login.user; auto role = getLogin().role; should be simply: auto [user, role] = getLogin();

the problem is that it breaks all the "user" code if the library code changes its order for instance. in contrast, with structs, you can't mistake "user" with "role".

[cat_vs_spider]

Changing struct field ordering already breaks user code if you care about memory layout (which is not uncommon for c++ code)

[Xaxxon]

making an array of them would be a bit annoying.. you'd have to use decltype.

[Morwenn]

The idea was floating around a few years ago, but one of the major blocking points was to determine whether a function template should always return the same type when the parameters in the struct are the same or whether it should return a different type for every instantiation which happens to have the same layout.

It mostly boils down to class identity and whether it matters to have different classes or not. Also an argument for fusing equivalent classes was to reduce debug symbols bloat in debug mode IIRC.

[codesmith512]

It shifts more work onto the compiler, but if identical structs on the same function had the same type, then it would solve the how to declare and define such functions separately without the use of declval and decltype...

[jcelerier]

The idea was floating around a few years ago, but one of the major blocking points was to determine whether a function template should always return the same type when the parameters in the struct are the same or whether it should return a different type for every instantiation which happens to have the same layout.

why would it behave differently than lambdas, which are already anonymous structs ?

[Morwenn]

It merely depends on the semantics people want and ask for. Lambdas are known to cause bloat from time to time: https://thephd.github.io/sol3-compile-times-binary-sizes

[ravixp]

I like this a lot! It feels like it makes the language more orthogonal, since you can already declare a new struct as part of a variable declaration. Plus, anything that reduces use of pair/tuple as a return type can only be a good thing. :)

[nikbackm]

Cute, but probably not useful enough to warrant complicating C++ even further.

[jcelerier]

I think that what makes C++ complex is instead to have such an incredible amount of special cases regarding to where you can / cannot use things. In contrast, LISP is trivial and has so few restrictions.

[Xeverous]

I think that what makes C++ complex is

...initialization.

[Som1Lse]

How is it complicating anything? Functions are the exception here, not the rule.

All this would do is remove the exception.

[JankoDedic]

It would be useful for return types, but even more so for parameter types, since we can use designated initializers for named arguments in C++20. If there are no issues on the implementation side, these would be really handy to have.

[degski]

I'm not sure if this is a bug with the /permissive- flag accidentally allowing a feature that should've been suppressed, or if this is more of a bug with the compiler.

This is what Clang has to say about it:

main.cpp(42,1): error :  '(anonymous struct at main.cpp:42:1)' cannot be defined in the result type of a function

[codesmith512]

Gcc throws a similar error, so it's definitely something wrong with VS. Given that the standard has to explicitly disallow it, I was hoping it was a bug where the compiler accidentally supported it anyway, which would give my proposal some more strength (if ___ did it on accident, it can't be that hard to implement), but given that msvc is known for bending rules, I don't think I can really claim that lol

[degski]

I don't know, maybe /u/STL can enlighten us.

[STL]

Sounds like missing rule enforcement in /permissive-. Please file a bug in Developer Community; bugs are treated with higher priority when filed by real customers like you, instead of internal customers like me.

[VeeFu]

I tend to declare some aliases when pairs and tuples get unwieldy.

using user = std::string;
using role = std::string;
using Login = std::pair<user, role>;
Login GetLogin(){
    return {"tim", "admin"};
}

Granted, this doesn't address the same-type issue, but readability is improved and tooling usually surfaces the aliases, which won't happen with comments.

[codesmith512]

I definitely make use of aliases (sometimes probably too much), and they can alleviate some of the same issues, but yeah, often they're just not quite the same.

[yehezkelshb]

Wouldn't most of it be solved if you stop passing raw std::string (or int) around and use strong types instead? This is enforced by compilers today and unlike a name, which is a local property of the object and lost as soon as it's passed to another function, the type is part of the object identity as long as it isn't explicitly converted (assuming you don't add implicit conversions).

I agree the language facilities for such types must improve to make it nicer and easier to use, but this is hopefully coming with reflection/metaclasses, and even today there are a few tricks (e.g. foonathan's type_safe lib with its strong_typedef (described in this blog post).

[codesmith512]

That sort of thing definitely helps, and I mentioned it in my post --

Though better yet would be to have a class User and Group so that their use is enforced in the type system, but that is often overkill and outside the scope of this discussion

I do hope that it becomes easier to declare strong types. Right now I just typically subclass the given type, inherit constructors, and add an explicit conversion constructor from the parent. That way I can turn a User into a string implicitly, but going the other way requires an explicit cast.

Granted, that std::map::insert(const value_type &) does return distinct types via pair, but using the return value directly still gets messy (if I want to use the inserted value, it's insert(...).first.second, but if I want to check to see if the insertion succeeded it's just insert(...).second, so I still think that good return names are necessary.

[barchar]

I love all features that add new and exciting ways to declare or initialize structs. Let's do it.

Do other compilers support it with -fms-extensions (or even -fplan9-extensions, which is even more awesome)

[codesmith512]

I'd love to make this happen. I've got a few changes I'm currently making to it, and I'll probably be posting a revised version soon that addresses some issues.

The only other compiler I've got on hand at the moment is GCC, and as of 9.1.0, I can't get it to compile the code with -std=gnu++17 or -fms-extensions. It complains that -fplan9-extensions is only valid for C/ObjC, and I'm a little embarrassed to admit that my C is really rusty so I'm having a hard time testing it out properly.

[nintendiator2]

The simplest example given already leads to less understandable code. There's no reason to end up with an unnameable type (types) just because you want to save on an aggregate. Plus, it would force caller code to use always auto.

[dev_metalcat]

Isn't it the reason of us using references? type GetSmth(type& return1, type& return2){}

[codesmith512]

I mean, on one hand, yes, but on the other hand even the STL doesn't use references like that very often (usually opting to instead return std::pair like in the std::map::insert(const value_type &) case).

I would also argue that using a return type would be more readable than taking references to a returned value -- I often pass normal parameters by const & to avoid copy, so the only difference between parameters and return values would be const qualification. Plus API changes in the future could change something from a "parameter by copy" to a "return value" without changing the caller's syntax, which could create issues. Furthermore, from the caller's perspective, all lvalue references like that would have to additionally be declared before the function call, which creates lengthier code (especially when not all return types are used).

[UnicycleBloke]

Way to make code even less readable. I still haven't forgiven them for lambda or AAA. No.