我正在实施BTreeMap<K, V>的替代方案.在此之上，我正在构建一个BTreeSet，它是一个围绕type MyBTreeSetContents<T> = MyBTreeMap<T, ()>的包装器.
在内部，该BTree的叶 node 包含Vec<(K, V)>个值.
在BTreeSet的情况下，这就变成了Vec<(K, ())>.
我想在BTreeSet中的值引用上提供一个快速迭代器.产生&T的迭代器.但到目前为止，在不使用Transmut的情况下，我所能得到的最好结果是一个产生&(T, ())的迭代器.
因此，问题是:
K、(K, )和(K, ())的内存表示法是否相同？(K, ())到K之间转化是可以的吗？Vec<(K, ())>改成Vec<K>行吗？如果有其他方法可以避免std::mem::transmute人的使用，当然也会非常感激！
No.就目前执行的情况而言，不能保证将(T, ())人转化为T人.元组使用默认表示，除了The Rust Reference中所说的以外，这并不意味着布局的任何内容.只有#[repr(transparent)]个能保证布局兼容性.
然而，它可能会奏效，并可能最终得到保证.从不安全代码指南中的Structs and Tuples开始:
一般说来，N的匿名元组类型
(T1..Tn)的布局就好像有相应的元组 struct 一样……...
对于 struct 布局1-ZST[1]字段被忽略.
具体地说，如果除一个字段外的所有字段都是1-ZST，则该 struct 等价于单字段 struct .换句话说，如果除一个字段之外的所有字段都是1-ZST，则整个 struct 与该字段具有相同的布局.
例如:
type Zst1 = (); struct S1(i32, Zst1); // same layout as i32[1]大小为零的类型称为零大小类型，缩写为"ZST".本文还使用了"1-ZST"缩写，代表"一对齐零大小类型"，指的是对齐要求为1的零大小类型.
如果我对这一点的理解是正确的，(K, ())的布局与K相同，因此可以安全地变形.然而，这不会扩展到像《RustonomicalTransmutes》中提到的那样，将Vec<T>转化为Vec<U>:
即使是同一泛型类型的不同实例也可能具有非常不同的布局.
Vec<i32>和Vec<u32>might的字段顺序相同，也可能不同.
不幸的是，你应该对此持保留态度.不安全代码指南旨在推荐unsafe个代码可以依赖的代码，但目前它只将自己宣传为正在进行的工作，语言规范中的任何具体补充都将转移到官方的Rust参考中.我说这"可能会奏效"，因为指导方针的一个方面是记录当前的行为.但到目前为止，参考文献中还没有提到这样的保证.