aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/MC/MCDisassembler/Disassembler.cpp
diff options
context:
space:
mode:
authorHoward Hinnant <hhinnant@apple.com>2012-04-01 23:10:42 +0000
committerHoward Hinnant <hhinnant@apple.com>2012-04-01 23:10:42 +0000
commit0527c6207af5de565bbd77e64f953bbc785cee8d (patch)
tree2d0a9a080fe505fe562b4072bd60993b22fd6ff9 /llvm/lib/MC/MCDisassembler/Disassembler.cpp
parent0090df24d75ddd9ab2d4b913cf74d613b09a2335 (diff)
downloadllvm-0527c6207af5de565bbd77e64f953bbc785cee8d.zip
llvm-0527c6207af5de565bbd77e64f953bbc785cee8d.tar.gz
llvm-0527c6207af5de565bbd77e64f953bbc785cee8d.tar.bz2
I believe tuple is still under development in the standard. Daniel Krugler is/will be making convincing arguments that a modified form of LWG 2051 (currently NAD Future) is easily acheivable and desirable. He has demonstrated that a tuple<T...> where all of the T are implicitly convertible from U... should have a tuple constructor that is also implicit, instead of explicit. This would support the use cases in LWG 2051 while not undermining T... with explicit conversions from U.... This check-in is an experimental implementation of Daniel's work. I believe this work to be mature enough to warrant inclusion into libc++. If anyone sees real-world problems that this check in causes, please let me know and I will revert it, and provide the feedback to the LWG.
llvm-svn: 153855
Diffstat (limited to 'llvm/lib/MC/MCDisassembler/Disassembler.cpp')
0 files changed, 0 insertions, 0 deletions