Stl: Consider replacing _STD forward<T> with static_cast<T&&>

[StephanTLavavej]

Replacing _STD forward<T> with static_cast<T&&> STL-wide would:

• Improve performance in non-optimized debug mode (by avoiding real function calls)
• Improve compiler throughput by some, possibly extremely small, amount. (Probably more significant for non-optimized debug mode.)
• Reduce readability, by making it harder to tell when we intend to forward, and harder to notice static_casts doing other work.

The current convention is to use forward except when we are in such a central header that it isn't available, or in certain rare situations where we seem to be exceptionally concerned about the perf/throughput effects.

Originally filed as Microsoft-internal VSO-541778 / AB#541778 .

[StephanTLavavej]

I personally believe that we shouldn't do this. Instead, the compiler should implement Microsoft-internal VSO-437566 " C1XX should understand move and forward, and not emit functions into the obj/PDB". (Clang should do the same, if it doesn't already.) I am deeply concerned about the readability impact, and teaching the compiler to understand move and forward would help all modern C++ projects, not just the STL.

[MikeGitb]

" C1XX should understand move and forward, and not emit functions into the obj/PDB"

I know this is not the compiler feedback channel, but YES PLEASE!

Personally I never understood, why such fundamental constructs have to be provided by the library and not by the compiler in the first place, but thats a different can of worms.

[AlexGuteniev]

Can't you just have _STD_FORWARD macro that hides static_cast? It is not "bad, control flow macro", although not "good, conditional feature macro" either

Edit: I typed _STD_MOVE for some reason, but I guess the decision can be replayed to move either, movecan be implemented using static_cast too

[AlexGuteniev]

Honestly I'm surprised that /O0 builds have that much of performance considerations.

Wanna debug with overall release performance? Use #pragma optimize("", off) in the place being debugged. (And this is sort of last resort option for me; normally I just debug release)

[StephanTLavavej]

I would be somewhat nervous about adding a _STD_FORWARD macro using decltype although I can't immediately imagine a scenario where it would cause harm.

[AlexGuteniev]

It is _STD_MOVE needs decltype, _STD_FORWARD takes T&& as the first parameter.

[NN---]

Reminds this article https://foonathan.net/2020/09/move-forward/

[MikeGitb]

@StephanTLavavej : Just wondering: Have you actually talked about this with the comiler devs?