[libcxx-commits] [PATCH] D115686: [libc++] [P0849R8] Introduce _LIBCPP_AUTO_CAST(x) for auto(x)

[Arthur O'Dwyer via Phabricator via libcxx-commits]

Quuxplusone added a comment.

In D115686#3205591 <https://reviews.llvm.org/D115686#3205591>, @ldionne wrote:

> Is there really no other place that uses `decay-copy` in the standard? If so, they forgot to remove it from http://eel.is/c++draft/expos.only.func#2.

It's still used as a specification tool in a few places — notably even within Ranges, e.g. http://eel.is/c++draft/range.take#overview-2.1 "If `T` is a specialization of `ranges​::​empty_view`, then `views​::​take(E, F)` is expression-equivalent to `((void) F, decay-copy(E))`, except that the evaluations of `E` and `F` are indeterminately sequenced." The Standard can't literally say it's expression-equivalent to `((void) F, (E))`, because then if `E` were a prvalue then the return object of `views::take(E, F)` would have to work out to the exact same prvalue object as the function argument `E`... and that's physically impossible. So they specify it in terms of `decay-copy`. Also, they have to say "indeterminately sequenced" because `E` and `F` are really function arguments, and function arguments are indeterminately sequenced.

Basically, `decay-copy(X)` is now purely a specification tool. When LWG means `return func(X)`, LWG can say "expression-equivalent to `func(X)`"; but when LWG means literally `return X`, then LWG must say "expression-equivalent to `decay-copy(X)`." However, as shown in D115686 <https://reviews.llvm.org/D115686>, my interpretation is that the library implementor //never// wants to //use// `__decay_copy(X)`; when the standard says "expression-equivalent to `decay-copy(X)`", the library implementor should generally reverse-translate that into simply `return X`.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D115686/new/

https://reviews.llvm.org/D115686