[llvm-bugs] [Bug 20855] tuple with a reference to a temporary (C++11): static_assert: "Attempted to construct a reference element in a tuple with an rvalue"

via llvm-bugs llvm-bugs at lists.llvm.org
Sat Oct 21 21:06:56 PDT 2017


https://bugs.llvm.org/show_bug.cgi?id=20855

Edward Z. Yang <ezyang at mit.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |---
                 CC|                            |ezyang at mit.edu

--- Comment #11 from Edward Z. Yang <ezyang at mit.edu> ---
I am reopening this to disagree.

There are three main arguments why clang should not reject this:

1. No where in the C++ standard is a tuple of references prohibited. 
Introducing a restriction, in the name of a "diagnostic", introduces
portability issues (where use of a reference in a tuple is allowed on one
compiler, e.g., gcc and old versions of clang) and disallowed on other
compilers.  Sure, introduce *warning* for a diagnostic, but don't make it a
fatal error.

2. It's inconsistent with clang's treatment of pair. std::pair<const int&,
const int&> works just fine; it is only tuple that is rejected. Are you going
to also attach this diagnostic to pair?

3. This construction is useful anywhere you (1) would have returned a reference
/ const reference, and (2) need to return multiple values.  Many of the
examples given by users in the ticket here were "wrong", and you definitely
have to be careful to use the correct constructor (lest reference collapsing
occur), but there truly is nothing wrong with wanting to return multiple
references from a function, to data whose scope extends beyond the immediate
function call.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20171022/ea22bccd/attachment.html>


More information about the llvm-bugs mailing list