[PATCH] D113393: [c++2b] Implement P0849R8 auto(x)

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

Quuxplusone added a comment.

In D113393#3345275 <https://reviews.llvm.org/D113393#3345275>, @aaron.ballman wrote:

>> Also implemented decltype(auto)(x) (https://wg21.link/p0849r2) as a Clang extension.
>
> I'd like to better understand the use cases for this. WG21 considered this as part of the feature and ultimately rejected it (fairly strongly, according to the EWG polls). From the meeting minutes, it says that the reason EWG disliked the idea is because of its expert-friendly nature and that this facility would present teachability issues. I tend to agree, so I'm wondering why we want to add the feature as an extension when WG21 explicitly rejected it (that doesn't seem in line with our extension policy: https://clang.llvm.org/get_involved.html#criteria).

(I'm not directly answering Aaron's question.)  Personally I think it makes sense to support `decltype(auto)(x)` in the same release as `auto(x)`, for the same reason we supported `Constrained decltype(auto)` in the same release as `Constrained auto`. //But//, rather than have that essentially tangential policy discussion in //this// PR, @lichray, would you be willing to split out all the changes related to `decltype(auto)(x)` into their own separate PR, (1) so that we could land the uncontroversial C++20 `auto(x)` parts sooner rather than later, and (2) so that if three years from now someone //does// decide to revert `decltype(auto)(x)`, all its changes will be nicely isolated in their own commit instead of mixed in with important bits of our C++20 conformance? And (3) so that we could have the "Should we do this?" policy discussion in //that// PR, instead of here, and (4) the discussion would be more focused because we could see //exactly// the set of diffs we're talking about, instead of mixed in etc etc.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113393