The logger implementation we have is "deferred". When you call LogValue, it
saves data to an in-memory data structure, and that data structure saves to
disk later on. It means the expensive part is deferred until after all the
important work is done, and can be optimized via batching some operations.
It also means that the LogValue function can itself be optimized by moving
from it's argument into the in-memory data structure, instead of copying,
when provided with an rvalue.

On Sun, Jan 17, 2021 at 9:21 AM Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Sun, Jan 17, 2021 at 4:27 AM Drew Gross via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > Some examples of when you don't want to forward a forwarding reference,
> might be easy to create bugs if it forwarded automatically:
> >
> > 1) A generic logging wrapper function
> > ```
> > auto LoggedCall(auto >&& f, auto >&& v) {
> > LogValue(v);
> > return f(v); // Oops, v was moved from! (Maybe, depending on
> signature of LogValue)
> > }
> > ```
>
> Why would a logging function move from its parameter? It should take
> it as a `const&`.
>
> > 2) A generic concatenate function
> > ```
> > auto Concatenate(auto >&& c1, auto >&& c2) {
> > std::vector<decltype(c1)::value_type> result;
> > using std::size;
> > result.reserve(size(c1) + size(c2)); // Oops! c1 and c2 were moved
> from (OK only if size's signature is weird for c1/c2's type, but you get
> the point)
> > // ... add c1 and c2 to result ...
> > return result;
> > }
> > ```
>
> Again, why would `size` move from its parameter?
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>