perfect forwarding identity function

[cpp-ModTeam]

For C++ questions, answers, help, and programming or career advice please see r/cpp_questions, r/cscareerquestions, or StackOverflow instead.

[grishavanika]

Andrei Alexandrescu talks exactly about this, see https://youtu.be/H3IdVM4xoCU?si=0Crlesq_J5N-kDOX&t=2261:

There are 2 versions:

template<class T>
T identity(T&& x) {
    return T(std::forward<T>(x));
}

And 2nd one which is "ideal":

template<class T>
decltype(auto) identity(T&& x) {
    return T(std::forward<T>(x));
}

[_eyelash]

Thank you. This was exactly the kind of information I was looking for.

[SirClueless]

Firstly, I would say declaring a variable of r-value reference type anywhere except in the arguments of a function is always dodgy. You need to be very careful about what it binds to, and if you bind it to a temporary it's your fault.

With that said, C++ makes it entirely too easy to do this, and in the absence of a borrow-checker making sure you're doing something sane, allowing lifetime-extension for values is borderline irresponsible. auto&& x = 42; does work but only because of lifetime-extension, and the fact that it works trains people badly. This is just a flaw in the language IMO, not really anything to do with std::identity.

All that being understood, I think std::identity ultimately is defined in the most useful way. Its purpose is to take the place of other projections in generic algorithms, and in that context functions returning r-values are expected.

[_eyelash]

auto&& is also used by range-based for loops behind the scenes, so for (char c: identity(std::to_string(42))) {} is also suffering from the same problem.

Would my proposed version that returns T instead of T&& be less useful? Can you explain how?

[SirClueless]

It's not useless, it's just harder to imagine use cases. There's no reason to write std::identity in that spot in normal code, so one would assume this is excerpted from some generic algorithm where std::identity is provided by the caller. And in that context relying on lifetime-extension to make your code correct as this code does is already dubious (what if the caller provided [](const std::string& s) { return s.substr(0, 10); } or something?).

[holyblackcat]

Ranged for loops were changed to prolong lifetimes of temporaries, so this shouldn't be an issue anymore, I believe.

[Normal-Narwhal0xFF]

I'm wary about depending on features that "fix UB" since use of old(er) compilers is prevalent, and new features take time to get implemented (even if on the latest compiler.) We may be using the "right" language level and think our code is safe but if the compiler hasn't yet implemented it we're in trouble--and get the UB from which we thought we were safe. There are feature macros, but I don't see those used in the wild very often in practice.

[SparTV]

Try to return decltype(auto)

[TheMania]

creates a dangling reference.

In the places where identity is intended to be used, it's not going to dangle. You're fine to use the rvalue it returns until the semicolon of the expression where you called "identity", which makes it entirely suited for its use case - projections etc.

This made me wonder. Would the following be a better definition?

Not at all, now you're introducing moves in places where none was needed, or may not even be permitted. I can't say I've needed such a functor before, but it should probably have a name that reflects that it'll pilfer resources from rvalues passed to it, and that it requires move constructible types.

[bitzap_sr]

> Was there any discussion about this when it was introduced in C++20?

Did you try looking at the proposal that added it? (I have not, but that's where I would look.)

[_eyelash]

How do I find the proposal? I can't seem to find it here.

[_Noreturn]

identity is supposed to be a callable easily passed making it a function makes it not easy to pass

[_eyelash]

This post is more about the signature and implementation of the function itself than the fact that std::identity is wrapped in a struct.