Can't we just synthesize std::tuple_element from get?

• 语言: 英语
• 格式: .pdf
• 来源: github.com/CppCon

摘要

文档讨论了是否可以通过`get`函数合成`std::tuple_element`，并探讨了为什么需要专门化`std::tuple_element`。文中指出，`std::tuple_element`并不适合所有情况，尤其是当需要考虑值类别和const性时。此外，文档还提到结构化绑定（structured bindings）并不依赖`std::tuple_element`，而是通过`get`函数实现。最终建议避免使用`std::tuple_element`，并提出了一种替代方案，通过专门化`my_tuple_element`来解决类型问题。

AI总结

# 《我们不能通过 `get` 合成 `std::tuple_element` 吗？》

## 为什么需要专门定义 `std::tuple_element`？

文档讨论了 `std::tuple_element` 的作用及其必要性。`std::tuple_element` 的核心功能是获取元组中指定位置的元素类型。虽然可以通过 `std::get` 函数间接推导出元素类型，但 `std::tuple_element` 的特殊化设计是为了明确处理元组元素的类型信息，并且考虑了值类别（lvalue 或 rvalue）和 const 性质。

---

## 我们是否可以通过 `get` 合成 `std::tuple_element`？

文档尝试通过 `std::get` 函数来推导元组元素的类型，提出了以下方案：

template 
struct my_tuple_element {
    using type = decltype(get(std::declval()));
};

然而，这种方法存在以下问题：
1. **值类别和 const 性质的处理**：`std::get` 返回的类型可能与原元组元素的值类别和 const 性质不一致。
2. **临时对象的处理**：当元组是临时对象时，`std::get` 的返回类型可能需要额外处理。

此外，文档指出，即使是结构化绑定（structured bindings），也不依赖于 `std::tuple_element`，而是直接通过 `std::get` 获取元素类型。

---

## Jonathan Müller 的观点：**“你应该永远不要使用 `std::tuple_element`！”**

Jonathan Müller 强调：
- `std::tuple_element` 的设计无法满足对值类别和 const 性质的精确处理。
- 在实际使用中，`std::tuple_element` 的特性（如返回引用而非值）可能导致类型推导不准确。
- 对于现代 C++ 开发，`std::tuple_element` 的功能已经被其他更灵活的解决方案（如结构化绑定）所取代。

---

## 文档的贡献：对自定义元组类型的结构化绑定支持

文档作者提出了一个自定义的元组类型 `my_tuple`，并尝试通过以下方式实现对结构化绑定的支持：

template 
struct my_tuple_element {
    using type_temporary = decltype(get(std::declval>()));
    static constexpr auto stores_reference = !tc::is_temporary;
    using type = std::conditional_t>;
};

该实现旨在处理临时对象的引用问题，但仍然暴露了一些复杂性，例如：
- 对临时对象的处理需要额外的类型 trait（如 `tc::is_temporary` 和 `tc::remove_temporary_t`）。
- 值类别的处理仍然不够灵活。

---

## 总结

文档的核心观点是：
1. **`std::tuple_element` 的设计存在局限性**，尤其是对值类别和 const 性质的处理不足。
2. **结构化绑定不依赖 `std::tuple_element`**，而是通过 `std::get` 函数实现类型推导。
3. 对于自定义元组类型，实现结构化绑定支持需要复杂的类型处理逻辑。

Jonathan Müller 的观点进一步强调了 `std::tuple_element` 的局限性，并建议在现代 C++ 开发中避免使用。