#define SLOT_TYPE(__str__, __type__) param(__str__) = std::remove_reference_t{}

#define DECLARE_NAMED_TUPLE(…) decltype(namedtup::make_named_tuple(__VA_ARGS__))

… right? but then if you are using a tuple in a return statement like:

return make_named_tuple(param(“yodogg”) = 42);

… that yields a different type than, say:

int integer = 42;
return make_named_tuple(param(“yodogg”) = integer);

… the named parameter in first example, with the literal integer, has type int whereas the second example (in which the param value is stored in a variable) has type int &.

This makes the named tuple idiom, as implemented here, much less useful. I have tried to monkey around with this code, in order to deal with references in the manner I’ve described here, but it seems non-trivial to implement (especially in the case of struct types, where pass-by-reference is desirable). If there’s a solution to this, I’d be interested in seeing what it is, as I still like the named tuple idea. Yes!

Named tuple has advantages of std::tuple. As they have comparison operation out of the box you can pass result into std::sort for example. And more – such structure could be extended to support additional functionality in future (such as serialisation to JSON, easy introspection, concatenation of such tuples, iterations over list of members, etc)

auto f = [](){
enum { GPA, grade, name };
auto student = make_tuple(3.8, ‘A’, “Lisa Simpson”);
return student;
};

And if you go this way – it’s better use custom struct instead of enum.

Once again – proposed solution is for cases where you used std::pair / std::tuple in your code. I’m not suggesting to replace structs/classes as return types.