This is an archive of the discontinued LLVM Phabricator instance.

[Clang] Implement decltype(auto)(x) from P0849R2
AbandonedPublic

Authored by lichray on Feb 25 2022, 12:51 PM.

Details

Reviewers
aaron.ballman
cor3ntin
Quuxplusone
rsmith
Group Reviewers
Restricted Project
Summary

As a Clang extension. See also https://wg21.link/p0849r2

The implementation takes a shortcut by forming CXXFunctionalCastExpr.
Doing so costs losing 'decltype(auto)' keyword in AST. Although
we do that elsewhere, because this is in an expression, it's more
difficult to keep AST print legal *and* trustworthy.

Depends on D113393

Diff Detail

Event Timeline

lichray created this revision.Feb 25 2022, 12:51 PM
lichray requested review of this revision.Feb 25 2022, 12:51 PM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 25 2022, 12:51 PM
Herald added a subscriber: cfe-commits. · View Herald Transcript

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, [...]

Not intended to argue for something when people who were against do not present - it's an awkward keyword for std::forward, arguably shorter, safer, faster...

lichray updated this revision to Diff 411842.Feb 28 2022, 10:39 AM
This comment was removed by lichray.
lichray updated this revision to Diff 411845.Feb 28 2022, 10:42 AM

Restore the right diff

aaron.ballman added reviewers: rsmith, Restricted Project.Mar 25 2022, 7:26 AM

I'm adding more reviewers for a wider audience on this topic. Personally, I don't think we should support this extension. EWG voted pretty strongly against it: 0/3/7/6/1 (https://github.com/cplusplus/papers/issues/293#issuecomment-585662477) and Clang has a policy that language extensions should have representation within the appropriate governing body (https://clang.llvm.org/get_involved.html#criteria). Given that the governing body for this rejected it and there's not a significant user benefit to supporting it, I think we shouldn't step into the C++ design space for this extension. However, I have no idea how others feel.

Herald added a project: Restricted Project. · View Herald TranscriptMar 25 2022, 7:26 AM

I'm adding more reviewers for a wider audience on this topic. Personally, I don't think we should support this extension. EWG voted pretty strongly against it: 0/3/7/6/1 (https://github.com/cplusplus/papers/issues/293#issuecomment-585662477) and Clang has a policy that language extensions should have representation within the appropriate governing body (https://clang.llvm.org/get_involved.html#criteria). Given that the governing body for this rejected it and there's not a significant user benefit to supporting it, I think we shouldn't step into the C++ design space for this extension. However, I have no idea how others feel.

I tend to agree, EWG seemed quite against this (though sadly, it looks like the minutes never got uploaded to the wiki). For something to fail the 'is a problem worth solving' (aka, the 'author should do more work' vote) it means the room was quite against it. While I can see the attraction of this, I don't think it is a good feature.

lichray abandoned this revision.Mar 25 2022, 9:34 AM