Lightning Talk: Can't we Just Synthesize std::tuple_element From Get?
summary
Claims synthesis: std::tuple_element can be computed as decltype(get(obj)) so structured bindings wouldn’t need separate specializations. Implements a detector that calls get on lvalue and rvalue (and const variants) to see if the element is reference-preserving and then strips or keeps references accordingly. Fails on proxy/transform-like types where calling get twice is expensive or ill-formed and on subtle temporary/lifetime cases, so it works for many types but breaks for proxy ranges and cannot fully replace the standard requirement.
AI-written summary · about
chapters (10)
- 0:00Introduction
- 0:24The problem with tuples
- 1:17First attempt at a solution
- 1:47Second attempt and refinement
- 2:08Third attempt and more failures
- 2:42Final attempt at a solution
- 2:57Issues with transformation
- 3:29The case against tuple_element
- 3:55Structured bindings and get
- 4:53Conclusion and Q&A
related talks
07mLightning Talk: Higher-Order Template Metaprogramming with C++23
01h 00m++namedtuple - Python-style Named Tuples in C++20
06mLightning Talk: C++20 - A New Way of Meta-Programming?
01h 10mType Deduction and Why You Care
06mLightning Talk: Fun with Pointers to Members
46mType safe C++? LOL!
54mAdvanced TypeScript
52mTypescript Deep Dive