Folyd's Blog

我的 2022 总结

2023-01-05T00:00:00Z

从来没有写过年终总结，今年尝试总结一下，主要希望自己多年以后再来回顾能有新的感触和收获。废话不多说，开始：

回顾

To-D 观察室

2021 年 12 月 23 号开始在字节内部搞了一个叫《To-D 观察室》的专栏 (对外版: https://2d2d.io/)，主要是分享 To-D 开发者行业相关的动态和故事，可能有点类似于开发者版的《浪潮之巅》。大概四个月时间里，我总共发布了两季，写了 12 篇文章，后来因为 4 月份有其他事情，所以就停更了。可一旦停更了，要想继续更新真的就没那么容易了。因为要写这些文章实在需要花太多时间，我想把这些时间用来做一些其他事情。不过我对 To-D 行业的关注依然没有中断，于是我搞了一个同名的《To-D 观察室》飞书群和 Telegram 频道，不定期在里面分享我了解到的最新行业动态，每一篇都比较短，我只需要在几句话之类把某个动态的重点讲清楚就行，不需要花太多时间，所以这件事我一直坚持下来了。截止到 2022 年底，《To-D 观察室》的飞书群有 639 人，Telegram 上有 737 个订阅，个人感觉还是很不错的，特别是飞书群里面还有好多字节内部的大佬加入，其实还挺有压力的。

我很希望《To-D 观察室》可以一直帮助到关注这个领域的人，但更重要的是他对我个人也很有帮助，一方面丰富了自己的行业知识和阅历，也锻炼了自己归纳分析、总结重点的能力，另一方面，好记性不如烂笔头，我总结的这些也是为了方便我以后检索。一举多得，何乐而不为呢！

2023 年我会一如既往保持更新的！

Zine

写这个《To-D 观察室》专栏的时候确实没有想到这件无心插柳的事情能得到了字节内部很多人的喜欢，所以让我萌发了一个把他对外发布出去的想法。不过我是一个早期互联网去中心化、开放理念的忠实拥趸，所以我从来没有考虑过要把我的这些文章发布到微信公众号或者知乎专栏这样的平台，就算这些平台可以更方便获取流量甚至投放广告变现。因为最初我搞《To-D 观察室》就是按 10 篇文章为一季的方式发布的，这种比较类似杂志，因此我决定依然以杂志的方式对外发布。简单调研过社区上的项目，我发现并没有一个专门针对杂志的静态网站生成器，于是我决定用 Rust 自己写一个，名字就叫 zine。

zine 发布没多久很快就上了 GitHub Rust trending 榜，没过多久又被国外的人发到 HackerNews 上了，并且还上了 HackerNews 热榜，当时 star 数涨得飞快！想起我以前提交过好几次 HackerNews 都是石沉大海，没想到别人帮我提交反而上了热榜。

从 2 月 25 号开始写第一行代码，到 3 月 20 号发布第一个版本，过去一年 zine 总共发布了 9 个版本。Star 数超过 760，fork 数 30，但下载量只有 1.3k，属于是一个非常小众的产品了。不过不管多少人下载，我都会一直更新下去的。毕竟 2022 年我用 zine 搞了至少 5 份杂志，我从小就喜欢看杂志，我也很喜欢杂志这种出版物，所以开发 zine 永远会让我乐在其中。

2d2d.io -《To-D 杂志》，这也是我用 zine 创建的第一份杂志。
o11y.cn -《O11Y 杂志》，本来想搞一份专注于可观测性(Observability)领域的技术杂志，但是精力有限没搞了。
现代诗杂志 - 搞着玩的现代诗杂志。
The Whitepaper - “某运动”当天马上搞出来的杂志，现在这个杂志每天都会有一个叫 Paranoic 的机器人提交一篇空白文章，只要 Github 没有倒闭，他就会永远更新下去。

Paranoic 是痴心妄想者的意思，也意味着所谓的言论自由并不知道会不会实现，也不知道什么时候会实现。

Rust Magazine - 这是我 12 月份搞的 Rust 英文杂志，其实很早就想搞了，但是对自己的英文写作能力还很担忧，没想到 11 月底 ChatGPT 的出现马上就提高了我搞这份杂志的信心。这份杂志的很多内容我都是用 ChatGPT 帮忙写的。我只准备了一篇 Announcing 的文章就发布到社区了，没想到收到了非常大的反响，这让我欣慰至极也倍感压力。

Rust Search Extension

Rust Search Extension 诞生于 2018 年 10 月，如今已经进入第 5 个年头了，我依然在维护这个产品。2022 年总共发布了 5 个版本，我也很高兴它收到了越来越多人的喜爱。值得一提的是，今年在 Reddit 上有两条评论让我感触很深。

第一条是一位用户回复了一段很长的内容，大概意思就是我应该把这些好用的功能往 rustdoc，docs.rs 上提 PR，插件自身专注于搜索。这真的是一个非常好的问题，我之前也思考过，但是我没有这么做，最大的原因可能是因为我更追求"自由"。自己的产品，想做什么功能都是我一个人能决定的，如果往 rust 提 PR，事情就没那么容易了，没有那种“自由”。

第二条的评论则是感动，被人认可真的是世界上最幸福的事情啊。

After having used this extension for a while now, I'm in awe of the genius idea to make it. At first, I thought to myself that this is largely unnecessary thing, and a rather silly thing. I was just shocked of how much I love it now. It is beyond invaluable to me, atleast compared to my initial impression.

duo

duo 是一个集成 tracing 和 JeagerTracing 的可观测性项目，把 demo 搞完之后，还很荣幸受 Datenlord 的邀请参加了 2022 年的开源之夏活动，活动也顺利完成。不过今年实在没有太多额外的时间，所以后面基本上属于挖坑不填的状态了。2023 年要不要继续做我也不知道，时间永远都是有限的，如果我没有继续做，那说明我去做其他我认为更重要的事情去了。

其他值得一提的事情

年初参加了 RustTalk 播客的第一期录制，也是我第一次受邀录制播客，在播客软件里面听到自己的声音感觉非常有意思。
上半年很荣幸获得 Rust Foundation 的赞助，主要赞助我下半年持续开发 Rust Search Extension 和 zine。
圣诞节又受邀参加了国外的 Rustacean Station 播客的录制，主要是分享 Rust Magazine。第一次用英语和外国人聊了一个小时，节目还没有发出来，不知道效果怎么样。
今年我的 Twitter 涨粉好多，感觉至少涨了两三千？Github 也涨了 200+?

不变和改变

不变

依然坚持自己的兴趣爱好，乐理、钢琴、摇滚/后摇、纪录片等等；
依然对世界充满好奇，维基百科永远是我的宝藏，我已经忘了什么时候开始的每个月都会小额捐赠一笔美金给维基百科基金会，除了书本，我其他很大部分知识全是通过它来获得的；
依然理想主义和极简主义；
依然保持一颗赤子之心；
依然很宅；

改变

会弹键盘了，虽说键盘和钢琴看起来很像，但其实它们就是两个完全不同的乐器，键盘也有非常多的东西要学，我还只学了一点皮毛；
喜欢上了看英超（又多了一项花时间的爱好）。英超不愧是世界第一联赛，不仅是球队和球星高水平，它的各种细节真的比西甲、法甲等其他联赛要好很多；
认识了很多新的朋友，这一点真的很开心！
更加关注时政，更加追求民主与法治；

没了，就这么多吧，明年再会！

Rust Pin 进阶

2021-12-20T00:00:00Z

去年我写了一篇关于 Pin 的文章，算是由浅入深介绍了 Pin 到底是怎么一回事，为什么需要 Pin。但只掌握那部分知识依然不够，所以这篇文章希望能系统性的梳理跟 Pin 有关的知识点，所以标题我命名为《Rust Pin 进阶》。

Pin API 剖析

要想深入理解 Pin，熟悉 Pin 所有的方法是必不可少的。除去 nightly 的 API 后，Pin 总共有 13 个方法：

// Pin<P> where P: Deref
impl Pin<P> where P: Deref {
  unsafe fn new_unchecked(pointer: P) -> Pin<P>

  fn as_ref(&self) -> Pin<&P::Target>

  unsafe fn into_inner_unchecked(pin: Pin<P>) -> P
}

impl<P: Deref<Target: Unpin>> Pin<P> {
  fn new(pointer: P) -> Pin<P>

  fn into_inner(pin: Pin<P>) -> P
}

impl<'a, T: ?Sized> Pin<&'a T> {
  unsafe fn map_unchecked<U, F>(self, func: F) -> Pin<&'a U>
    where
        U: ?Sized,
        F: FnOnce(&T) -> &U

  fn get_ref(self) -> &'a T
}


// Pin<P> where P: DerefMut
impl<P: DerefMut> Pin<P> {
  fn as_mut(&mut self) -> Pin<&mut P::Target>

  fn set(&mut self, value: P::Target) where P::Target: Sized
}

impl<'a, T: ?Sized> Pin<&'a mut T> {
  fn into_ref(self) -> Pin<&'a T>

  fn get_mut(self) -> &'a mut T where T: Unpin

  unsafe fn get_unchecked_mut(self) -> &'a mut T

  unsafe fn map_unchecked_mut<U, F>(self, func: F) -> Pin<&'a mut U>
    where
        U: ?Sized,
        F: FnOnce(&mut T) -> &mut U
}

这些方法可以分为两个大类：

Pin where P: Deref
Pin where P: DerefMut

之前的文章有说过，Pin 一般以 Pin<P<T>> 的形式来表示（P 是 Pointer 的缩写，T 是 Type 的缩写），所以 Pin 包裹的内容只能是智能指针（实现了 Deref trait 的类型都可以称为智能指针），对其他普通类型是没有意义的。因为 &T 和 &mut T分别实现了 Deref 和 DerefMut，所以 Pin<&'a T> 和 Pin<&'a mut T> 分别算这两大类下的特化实现。

初看起来这 13 个方法有点杂乱，但其实他们的设计非常讲究，甚至可以说存在对称性。按功能来划分的话，这些方法可以分为 5 大类，各个类别按可变性或是符合 T: Unpin 限定来细分为 2~3 种。其中可变的版本都以 mut 结尾，因为不符合T: Unpin 限定的 unsafe 版本都包含 unchecked。

功能	方法	备注
构造 `Pin`	`new()` / `new_unchecked()`	按是否满足 `T: Unpin` 限定来区分 safe 和 unsafe 两个版本。
转换 Pin 类型	`as_ref()` / `as_mut()`	将 `&/&mut Pin<P<T>>` 转换成 `Pin<&/&mut T>`。
获取 `Pin<P<T>>` 里面 `T` 的借用	`get_ref()` / `get_mut()` / `get_unchecked_mut()`	消耗所有权，拿到里面的 `T` 的借用。按可变性分为两个版本。因为 `&mut T` 是"万恶之源"，所以 `get_mut` 又按是否满足 `T: Unpin` 限定来区分 safe 和 unsafe 两个版本。
消耗 Pin 所有权，拿到里面的指针 P	`into_inner()` / `into_inner_unchecked()`	按是否满足 `T: Unpin` 限定来区分 safe 和 unsafe 两个版本。另外，为了避免和 `P` 自己的 into 类方法冲突，这几个 API 都设计成静态方法，必须通过 `Pin::into_inner()` 这种形式调用，不能用 `pin.into_inner()`。
Pin projection	`map_unchecked()` / `map_unchecked_mut()`	通常用来做 Pin projection。

只剩下两个方法没有归类到上面的表格中，它们也比较简单，分别是：

Pin::set() - 设置 Pin<P<T>> 中新的 T 的值。

Pin<&mut Self>::into_ref() - 将 Pin<&mut T> 转换成 Pin<&T>。

值得注意的是其实 new() 和 new_unchecked()， get_mut()与 get_unchecked_mut() ， into_inner() 和 into_inner_unchecked() 的实现是完全一样的，唯一的区别是 safe 版有 Unpin 限定。

pub const fn new(pointer: P) -> Pin<P> 
  where P: Deref,
         <P as Deref>::Target: Unpin {
    unsafe { Pin::new_unchecked(pointer) }
}

pub const unsafe fn new_unchecked(pointer: P) -> Pin<P> {
        Pin { pointer }
}

pub const fn get_mut(self) -> &'a mut T where T: Unpin {
        self.pointer
}

pub const unsafe fn get_unchecked_mut(self) -> &'a mut T {
        self.pointer
}

pub const fn into_inner(pin: Pin<P>) -> P
    where P: Deref,
            <P as Deref>::Target: Unpin {
    pin.pointer
}

pub const unsafe fn into_inner_unchecked(pin: Pin<P>) -> P {
        pin.pointer
}

为什么相同的代码要区分 safe 和 unsafe 两个版本呢？要解答这个问题，还是要回到 Pin 的本质。Pin 本质上解决的问题是在 safe Rust 下保证 Pin<P<T> 中的 T 的内存地址不会被改变（也就是不被 move），除非 T 满足 T: Unpin。保证 T 的内存地址不会被改变的本质是避免暴露T 或 &mut T（"万恶之源"）。暴露 T 的话，随随便便就能 move 掉它；暴露 &mut T 的话，开发者可以调用 std::mem::swap() 或 std::mem::replace() 这类方法来 move 掉 T。还有一条，Rust 里面 safe 和 unsafe 的边界一定要区分非常明确，不能有任何含糊。所以只要你不满足 T: Unpin ，然后需要构造 Pin<P<T>>、暴露 T 或者 &mut T 的方法都应该是 unsafe 的。

	满足 `T: Unpin`	不满足 `T: Unpin`
构造 `Pin`	safe	unsafe
暴露 `T`	safe	unsafe
暴露 `&T`	safe	safe
暴露 `&mut T`	safe	unsafe

比如，into_inner_unchecked() 虽然返回的是 P，但是它是间接暴露了 T 和 &mut T。因为你可以通过*P 或 &mut *P 轻而易举的拿到 T 或 &mut T。而你构造 Pin<P<T>> 的时候相当于是承若要遵守 Pin 的契约 的，但这步操作明显就违约了。

为什么 Pin::get_ref() 是 safe 的呢？因为它返回的是 &T，你没有办法 move 掉它：std::mem::swap() 类方法只支持 &mut T，解引用 &T 的话编译器会报错阻止你。（再一次感谢 rustc）另外需要强调的是内部可变性的类型。比如 RefCell<T>， Pin<&mut RefCell<T>>.into_ref().get_ref() 返回的是 &RefCell<T>，而 RefCell<T>::into_inner() 之类的方法可以拿到 T 然后 move 掉它。但是这个没关系，因为 Pin<P<T>> 的契约是保证 P 里面的 T 不被 move，而这里的 P 是 &, T 是 RefCell，并不是 RefCell<T> 里面的 T。只要没有额外 Pin<&T> 指向 RefCell<T> 里面的 T 就行，但是你构造 RefCell<T> 的时候其实已经自动杜绝这种可能了。因为 RefCell::new() 的参数是 value: T，早就把 T move 进来了。

类似的，Pin<&mut Box<T>> 保证的是 Box<T> 本身不被 move，而不是 Box 里面的 T。如果要保证 Box<T> 里面的 T 不被 move，直接使用 Pin<Box<T>> 即可。

Pin 额外的属性

#[fundamental]

使用#[fundamental]属性标记的 trait 是不受孤儿规则约束。所以你可以给 Pin<P<T>> impl 你本地的 trait。

use std::pin::Pin;

trait LocalTrait {}

impl<P> LocalTrait for Pin<P> {
}

#[repr(transparent)]

#[repr(transparent)] 这个属性可以让 Pin 拥有和里面 pointer 字段同样的 ABI 布局，在 FFI 的场景下会很有用。

#[repr(transparent)] 是 1.28 稳定的，详细可以看 release note：

The #[repr(transparent)] attribute is now stable. This attribute allows a Rust newtype wrapper (struct NewType<T>(T);) to be represented as the inner type across Foreign Function Interface (FFI) boundaries.

Pin 实现的 trait

再来看看 Pin 实现了哪些值得关注的 trait。

Unpin

impl<P> Unpin for Pin<P> where P: Unpin {}

因为 Unpin 是 auto trait，所以 Pin<P<T> 如果满足 P: Unpin ，则 Pin<P<T>> 也会实现 Unpin。而几乎所有 P 都会是 Unpin ，所以 Pin<P<T>> 几乎总会是 Unpin 的。这个实现很重要，特别是如果这里的 T 是 Future 的时候。不管你的 Future 是不是满足 Unpin，把你用 Pin<&mut ...> 包裹之后，它就是一个满足 Unpin 的 Future 了（因为 Pin 实现了 Future，后面会讲到）。很多异步的方法可能需要你的 Future 满足 Unpin 才能调用，而 async fn 方法返回的 Future 显然不满足 Unpin，这个时候往往需要你把这个 Future pin 住才行。比如使用 tokio::pin!() 这个宏。

use tokio::pin;

async fn my_async_fn() {
    // async logic here
}

#[tokio::main]
async fn main() {
    let future = my_async_fn();
    pin!(future);

    (&mut future).await;
}

另外，需要再次强调的是：

Pin 本身是不是 Unpin 跟 T 是不是 Unpin 没有任何关系，只跟 P 有关系。
Pin 能不能把 T pin 住跟 P 是不是 Unpin 没有任何关系，只跟 T 有关系。

上面两句话虽然有点绕，但是搞清楚了后，很多 Pin 的场景就不会懵逼了。

Deref 和 DerefMut

impl<P: Deref> Deref for Pin<P> {
    type Target = P::Target;
    fn deref(&self) -> &P::Target {
        Pin::get_ref(Pin::as_ref(self))
    }
}

impl<P: DerefMut<Target: Unpin>> DerefMut for Pin<P> {
    fn deref_mut(&mut self) -> &mut P::Target {
        Pin::get_mut(Pin::as_mut(self))
    }
}

这两个 trait 对 Pin 非常关键。只有实现了 Deref 后 Pin 才是智能指针，开发者才可以无缝的调用 P 的方法。值得注意的是，只有满足 T: Unpin ，才会给 Pin<P<T>> 实现 DerefMut。因为 Safe Rust 下，Pin<P<T>> 的职责之一就是不能在不满足 T: Unpin 的前提条件下暴露 &mut T。

另外，实现了这两个 trait 之后，分别可以解引用拿到 &T 和 &mut T，但这种解引用的方式和 get_ref()、get_mut() 是有区别的。以 &T 为例，假设有 let p = Pin::new(&T);, 解引用 p 拿到 &T： let t = &*p;，这里拿到的 &T 的生命周期其实等于 &Pin::new(&T) 的生命周期。而 Pin::new(&T).get_ref() 拿到的 &T 的生命周期和 Pin 自身的生命周期是相等的。

为什么会这样呢？我们把解引用智能指针的语法糖展开之后看看。

let p = Pin::new(&T);
// let t = &*p; 展开语法糖之后如下：
let t = &*Deref::deref(&p);

Pin 的 Deref 实现代码是：Pin::get_ref(Pin::as_ref(self))，而 Pin::as_ref() 的代码如下。通过对比，就能发现解引用拿到的 &T 的生命周期确实和 get_ref() 拿到的是不一样的。

impl Pin<P> where P: Deref {
    pub fn as_ref(&self) -> Pin<&P::Target> {
        unsafe { Pin::new_unchecked(&*self.pointer) }
    }
}

// 对比上面 Deref 的实现
impl<'a, T: ?Sized> Pin<&'a T> {
    pub const fn get_ref(self) -> &'a T {
        self.pointer
    }
}

另外一个值得注意的地方是 Pin::as_ref() 和 Pin::as_mut() 里面会解引用 self.pointer，其实就是会调用它的 deref() 或 deref_mut() 方法。这两个方法是由 P 自己实现的，所以这里会存在“恶意实现”把 T move 掉的可能性。但是这种“恶意实现”会被 Pin 的契约 排除掉：这是你自己“恶意实现”导致的，并不是由于使用 Pin 导致。

Pin::new_unchecked() 的文档特意强调到了这一点：

By using this method, you are making a promise about the P::Deref and P::DerefMut implementations, if they exist. Most importantly, they must not move out of their self arguments: Pin::as_mut and Pin::as_ref will call DerefMut::deref_mut and Deref::deref on the pinned pointer and expect these methods to uphold the pinning invariants.

use std::pin::Pin;
use std::marker::PhantomPinned;
use std::ptr::NonNull;
use std::ops::{Deref, DerefMut};

struct Unmovable {
    data: String,
    slice: NonNull<String>,
    _pin: PhantomPinned,
}

impl Unmovable {
    fn new(data: String) -> Pin<Boz<Self>> {
        let res = Unmovable {
            data,
            slice: NonNull::dangling(),
            _pin: PhantomPinned,
        };
        let mut bozed = unsafe { Pin::new_unchecked(Boz(res)) };

        let slice = NonNull::from(&bozed.data);
        // we know this is safe because modifying a field doesn't move the whole struct
        unsafe {
            let mut_ref: Pin<&mut Self> = Pin::as_mut(&mut bozed);
            Pin::get_unchecked_mut(mut_ref).slice = slice;
        }
        bozed
    }
}

impl Default for Unmovable {
    fn default() -> Self {
        Unmovable {
            data: String::new(),
            slice: NonNull::dangling(),
            _pin: PhantomPinned,
        }
    }
}

struct Boz<T>(T);

impl<T> Deref for Boz<T>  {
    type Target = T;
    fn deref(&self) -> &Self::Target {
        &self.0
    }
}

// “Malicious” implementations of DerefMut
impl<T: Default> DerefMut for Boz<T>  {
    fn deref_mut(&mut self) -> &mut Self::Target {
        let _s = std::mem::take(&mut self.0);
        &mut self.0
    }
}

fn main() {
   let mut unmovable = Unmovable::new(String::from("Malicious!!!"));
   unmovable.as_mut();
}

上面的例子，我们构造了一个 Pin<Boz<Unmovable>>，然后调用 as_mut() 方法的时候会解引用这个 Boz，Boz 有一个“恶意”的 DerefMut 实现，里面会 move 掉这个 Unmovable。但明明我是是把它 Pin 住了的。

Future

Pin 还实现了 Future，这个和 Unpin 关系密切，我们在接下来的部分统一讲解。

Unpin 和 Future

Rust 的 pinning API 让初学者困惑的一大难点就是 Unpin 的引入，往往很容易把人绕晕，所以我们必须要彻底搞清楚 Unpin，特别是它和 Future 的关系。

前面说过，Unpin 是一个 auto trait，几乎所有类型都实现了 Unpin，包括你没意识到的一些类型。比如：

&T: impl<'a, T: ?Sized + 'a> Unpin for &'a T {}
&mut T: impl<'a, T: ?Sized + 'a> Unpin for &'a mut T {}
*const T: impl<T: ?Sized> Unpin for *const T {}
*mut T: impl<T: ?Sized> Unpin for *mut T {}
其他，包括 Box, Arc, Rc 等等

注意这里是不管 T 满不满足 T: Unpin ，它们都是 Unpin。原因我们前面已经说了：Pin 能不能把 T pin 住跟 P 是不是 Unpin 没有任何关系，只跟 T 有关系。

第一篇文章有讲过，只有 std::marker::PhatomPinned ，包含 PhatomPinned 的类型，还有 .await 解语法糖之后的那个结构体是 !Unpin，这里不再赘述。

Unpin 是 safe trait

另外一个很重要的特点：Unpin 是一个 safe trait。也就是说你可以在 safe Rust 下给任意类型实现 Unpin，包括你的 Future 类型。

我们提前准备好两个 assert 函数，后面会用到：
fn assert_future<F: Future>(_f: F) {}
fn assert_unpin<T: Unpin>(_t: T) {}

use std::{
    future::Future,
    pin::Pin,
    task::{Context, Poll},
};

#[derive(Clone)]
struct Dummy(String);

impl Future for Dummy {
    type Output = ();

    fn poll(self: Pin<&mut Self>, _cx: &mut Context<'_>) -> Poll<Self::Output> {
        println!("{}", self.0);
        Poll::Ready(())
    }
}

// 不加这一行，编译器也会帮你自动实现 Unpin
impl Unpin for Dummy {}

fn main() {
    let dummy = Dummy(String::from("hello world!"));
    assert_future(dummy.clone());
    assert_unpin(dummy);
}

如果你要在另外一个 Future 中去 poll 这个 Dummy future 也是完全没有问题的。futures crate 甚至还提供了一系列 unpin 版的方法来帮助你做这件事，比如 FutureExt::poll_unpin() 。

pub trait FutureExt: Future {
    /// A convenience for calling `Future::poll` on `Unpin` future types.
    fn poll_unpin(&mut self, cx: &mut Context<'_>) -> Poll<Self::Output>
    where
        Self: Unpin,
    {
        Pin::new(self).poll(cx)
    }
}

可以看到这里是 &mut self，而不是 self: Pin<&mut Self>。

但是，pin projection 场景下需要特别注意，如果你的类型中有字段是 !Unpin 的，你就不能给这个类型实现 Unpin。具体可以看官网 Pinning is structural for field 。

为什么 Future 可以是 Unpin 的

可能有人就要问了，Pin 设计之初不是为了解决实现 Future 的那个自引用结构体不被 move 的问题吗？为什么还可以给 Future 类型实现 Unpin？原因是这样的：如果你实现 Future 的类型是自引用结构体，那当然不能是 Unpin 的，除此之外实现 Unpin 完全没问题。上面那个例子，也包括很多第三方库的 Future 类型，都不会存在自引用结构体，可以放心大胆 move，所以完全可以是 Unpin 的。另外一个好处是，完全可以用 safe 版的 Pin::new() 方法构造 Pin 去poll future，不需要跟 unsafe 打交道。

Pin 的 Future 实现

之所以移到这里来讲 Pin 的 Future 实现，是因为 1.56 有一个 PR #81363 把 P: Unpin 的限定去掉了。我们先来看一下为什么要给 Pin 实现 Future，然后再来分析为什么这里的 Unpin 限定可以放开。

impl<P> Future for Pin<P>
where
-   P: Unpin + ops::DerefMut<Target: Future>,
+   P: ops::DerefMut<Target: Future>,
{
    type Output = <<P as ops::Deref>::Target as Future>::Output;

    fn poll(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output> {
-       Pin::get_mut(self).as_mut().poll(cx)
+       <P::Target as Future>::poll(self.as_deref_mut(), cx)
        // self.as_deref_mut() 其实就是 unsafe { self.get_unchecked_mut() }.as_mut()
    }
}

给 Pin 实现 Future 的理由很简单，就是为了方便调用 poll()，特别是在 pin projection 的场景。因为 poll() 的 self 是 Pin<&mut Self> 类型，你没办法直接用 future 来调用 poll()。

error[E0599]: no method named `poll` found for struct `Dummy` in the current scope
  --> src/main.rs:35:20
   |
35 |         Dummy(String::from("hello world!")).poll(cx)
   |                                             ^^^^ method not found in `Dummy`

你必须要先构造一个 Pin<&mut Dummy> 才能调用 poll()。给 Pin 实现 Future 之后，你可以直接这样写：Pin::new(&mut dummy).poll(ctx)，要不然你还需要写 Future::poll(Pin::new(&mut dummy), ctx)。

再来看看为什么这里不需要 P: Unpin。首先，这个方法的目的是要去 poll P::Target 这个 Future，而 poll() 方法的 Self 是 Pin<P<T>>，self 是 Pin<&mut Pin<P<T>>>（注意这里有两层 Pin）。我们要把 Pin<&mut Pin<P<T>>> 安全地转换成 Pin<&mut T> 才能调用 P::Target 的 poll()。那查一下 Pin 的 API 来倒推一下，拿到 Pin<&mut T> 很简单，有 Pin::as_mut()，前后两个版本的最后都是调用 as_mut() 的，这里没问题。但 as_mut() 的签名是 &mut self，也就是我们要先拿到 &mut Pin<P<T>>。如果把 Pin<&mut Pin<P<T>>>还原成基本形式 Pin<P<T>> 的话，那 &mut 是那个 P，Pin<P<T>> 是那个 T。从 Pin<&mut Pin<P<T>>> 拿到 &mut Pin<P<T>> 其实就是需要从 Pin<P<T>> 拿到 &mut T。get_mut() 和 get_unchecked_mut() 两个方法都能满足，唯一的区别是 Unpin 限定，这也是那个 PR 改动的地方。没有 Unpin 限定的话，我们只能使用 unsafe 版的 get_unchecked_mut() 。但是这里是完全安全的，因为我们拿到 &mut Pin<P<T>> 后马上就调用 as_mut() 了，并不会 move 它。所以之前的 P: Unpin 是多余的。更多细节可以查看 Pin::as_deref_mut() 的文档和源码注释。

为什么需要 Unpin 限定

上面也提到过，有些异步相关的 API 需要你的类型满足 Unpin 才能调用。目前我所了解到的，这些 API 大致可以分为三类：

需要 &mut future 的场景。比如 tokio::select!()，这个宏需要你的 Future 满足 Unpin；
AsyncRead / AsyncWrite 的场景。比如 tokio::io::AsyncWriteExt 的方法需要你的 Self 满足 Unpin。
Future 本身就是符合 Unpin，并且不想直接和 Pin 打交道。上面提到的 FutureExt::poll_unpin()方法就属于这一类。

第 (2) 类主要跟 AsyncRead / AsyncWrite 的 self 需要 Pin<&mut Self> 有关，社区也有不少这方面的讨论，不是这篇文章的重点，感兴趣可以查看下面的资料。

futures-rs: Should AsyncRead and AsyncWrite take self by Pin?

tokio: Should AsyncRead/AsyncWrite required pinned self?

Tokio’s AsyncReadExt and AsyncWriteExt require Self: Unpin. Why and what to do about it?

其次，tower 也在考虑要不要加 Pin<&mut Self>：Pinning and Service.

关于第 (1) 类，主要原因是给 &mut Future 实现 Future 的时候指定需要了 F: Unpin。

impl<F: ?Sized + Future + Unpin> Future for &mut F {
    type Output = F::Output;

    fn poll(mut self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output> {
        F::poll(Pin::new(&mut **self), cx)
    }
}

所以归根结底需要搞清楚为什么这里需要 Unpin。先从场景谈起，假如我们有一个 future 需要在 loop 中不断地 poll 它，但是 Future::poll() 每调用一次就会消耗掉 self 的所有权。因此我们需要可变借用这个 future，避免消耗掉 future 的所有权。但是 &mut future 之后会存在 move 掉这个 future 的风险（“万恶之源”），所以要么你这个 future 是 Unpin 的，要么你就要把它 pin 住再可变借用它（也就是 &mut Pin<&mut future>）。而刚好 Pin where P: DerefMut 实现了 Future！（前面部分刚讲过的）而且 Pin 也是满足 Unpin 的！真的太完美了，我们干脆给 &mut F 实现 Future 吧，只要 F 满足 Future + Unpin 就行。这样的好处是如果你的 future 满足 Unpin，那你直接 loop 中多次 poll 就行，不用担心 move 的问题；如果你的 future 不满足 Unpin，那也没关系，把它 pin 住就好了。比如下面的例子，因为 tokio::time::Sleep 不满足 Unpin，你需要先使用 tokio::pin!() 把它 pin 住才可以编译通过。

use tokio::time::{self, Duration, Instant};

#[tokio::main]
async fn main() {
    let sleep = time::sleep(Duration::from_millis(10));
    tokio::pin!(sleep);

    loop {
        tokio::select! {
            () = &mut sleep => {
                println!("timer elapsed");
                sleep.as_mut().reset(Instant::now() + Duration::from_millis(50));
            },
        }
    }
}

另外，同样的道理，给 Box<F> 实现 Future 的时候也需要 Unpin。

impl<F: ?Sized + Future + Unpin, A: Allocator> Future for Box<F, A>
where
    A: 'static,
{
    type Output = F::Output;

    fn poll(mut self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output> {
        F::poll(Pin::new(&mut *self), cx)
    }
}

其他需要 Pin 的场景

经常碰到有人问类似"我这个场景是不是需要用 Pin 来解决？"的问题，我看了一下，根本跟 Pin 没有任何关系，于是会用这句经典名言回复他：

Rust 社区经典名言：Whenever you wonder if Pin could be the solution, it isn't.

Pinning API 是朝着通用性设计的，并不是只为了解决异步里面自引用结构体 move 的一个问题，其他一些场景也需要用到 Pin。

Intrusive collections

Intrusive collections（侵入式集合）是 Pin 的另外一个应用场景。 Pin 的文档上有提到 intrusive doubly-linked list （侵入式双链表）这个例子，但是对于其他侵入式数据结构也类似（比如侵入式单链表）。不过文档只有言简意赅的几句话，并不是很好理解，我在这里简单的总结一下。

首先需要了解 instrusive collections 是什么。我们平时用到的集合数据结构几乎都是 non-intrusive 的，比如标准库的 Vec，LinkedList 等。non-intrusive 类型集合的特点是集合中的元素和集合自身是完全解耦的，集合不需要关心每一个元素的类型是什么，集合也可以用来存放任意类型的元素。但 intrusive 类型的集合是一种完全侵入式的集合，它的 prev 或 next 指针是定义在元素上面的。

以 C++ 为例子，non-intrusive 的双链表可以这样定义：

struct Point {
    float x, y;
};

struct ListNode {
    Point val;
    ListNode *next, *prev;
};

而 intrusive 的版本需要这样写：

struct Point {
    float x, y;
    Point *next, *prev;
};

Rust 版 intrusive 的伪代码大概也是这样：

struct Point {
    x: f64,
    y: f64,
    prev: Option<Rc<Point>>,
    next: Option<Rc<Point>>,
}

可以看到两者最大的区别在于指针是放在集合上面还是放在元素上面。两种类型的集合各自有优缺点，而 intrusive 类型最大的优点在于性能更好，缺点也很明显，不通用，不同的元素需要重复定义集合。相关的知识不是本文的重点，更多详细信息可以看看下面的资料：

Google Fuchsia 提供的侵入式容器

Intrusive linked lists

Safe Intrusive Collections with Pinning

那为什么侵入式集合需要用到 Pin 呢？其原因在于元素之间互相有 prev 或 next 指针指向自己，如果中间某个元素发生 move 了，那其他元素指向它的指针地址就失效了，导致不安全行为。所以必须要用 Pin 来把元素给 pin 住！Rust 有一个叫 intrusive-collections 的库提供了众多侵入式的集合类型，另外 Tokio 里面也定义了侵入式集合，毫无疑问他们都用到了 Pin。

其他

其实，只要是需要处理防止被 move 的场景，理论上都需要用到 Pin 来解决。其他的 case 我暂时想不出来了，以后有发现新的场景再补充，或者如果大家知道其他场景欢迎告诉我。

总结

这篇文章稍微有点长，我们来总结一下：

Pin 的 API 设计很讲究，甚至充满对称性，它的方法大致可以分为 5 类。其中涉及到 Unpin 和 &mut T 又可以细分为 safe 和 unsafe 两种；
Pin 的 #[fundamental] 和 #[repr(transparent)] 很重要，但你一般不需要关心它；
Pin 实现的 trait 需要重点关注 Unpin ，Deref / DerefMut 和 Future，搞懂他们你才能完全掌握 Pin；
Unpin 和 Future 关系十分密切。Unpin 是 safe trait，理论上可以任意实现，Future 也可以是 Unpin 的。一些异步 API 中可能需要 Unpin 限定，需要理解它的原因，而不是一味的只顾使用。
Pin 是一种通用 API，除了 async / await 下需要 Pin 之外，也会有其他场景需要用 Pin 来解决，比如 intrusive collections。

文章中多次提到的 Pin projection 没有展开讲，下一篇文章再来详细探讨它。再会！

优化 Rust 标准库的 binary_search

2021-04-26T00:00:00Z

2021 年 5 月 6 号发布的 Rust 1.52 版将会包含我的一个 PR，将标准库 slice::binary_search_by() 的最好时间复杂度优化到 O(1)。PR 编号 #74024，从 2020 年 7 月初提交的 PR，到 2021 年 3 月 6 号才正式合并，其中包含 70 多条评论，前后历时大半年。这个 PR 虽然改动不算很大，但是笔者在其中也学到了不少知识点，所以特意写一篇文章总结一下，希望能帮助到大家。

首先看一下 slice::binary_search_by() 这个方法的示例来了解一下它的用途。

let s = [0, 1, 1, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55];

let seek = 13;
assert_eq!(s.binary_search_by(|probe| probe.cmp(&seek)), Ok(9));
let seek = 4;
assert_eq!(s.binary_search_by(|probe| probe.cmp(&seek)), Err(7));
let seek = 100;
assert_eq!(s.binary_search_by(|probe| probe.cmp(&seek)), Err(13));
let seek = 1;
let r = s.binary_search_by(|probe| probe.cmp(&seek));
assert!(match r { Ok(1..=4) => true, _ => false, });

这个函数的作用就是在给定的有序 slice 中二分查找目标值 seek。如果找到了返回 Ok(pos)，pos 即目标值所在的位置；没找到则返回 Err(pos), 这里的 pos 的位置可以用来将 seek 插入 slice 后依然保持有序。其他的 slice::binary_search()，slice::binary_search_by_key() 系列方法都是调用这个 slice::binary_search_by()，这里不再赘叙。

但是，1.52 之前的实现有一个小问题，如果 slice 中存在多个连续的目标值，则它会一直找到最后一个才返回，所以最好时间复杂度也是 O(log n)，而不是 O(1)，也就是找到了就马上返回。这是 1.52 之前的代码：

#[stable(feature = "rust1", since = "1.0.0")]
#[inline]
pub fn binary_search_by<'a, F>(&'a self, mut f: F) -> Result<usize, usize>
where
    F: FnMut(&'a T) -> Ordering,
{
    let s = self;
    let mut size = s.len();
    if size == 0 {
        return Err(0);
    }
    let mut base = 0usize;
    while size > 1 {
        let half = size / 2;
        let mid = base + half;
        // SAFETY: the call is made safe by the following inconstants:
        // - `mid >= 0`: by definition
        // - `mid < size`: `mid = size / 2 + size / 4 + size / 8 ...`
        let cmp = f(unsafe { s.get_unchecked(mid) });
        base = if cmp == Greater { base } else { mid };
        size -= half;
    }
    // SAFETY: base is always in [0, size) because base <= mid.
    let cmp = f(unsafe { s.get_unchecked(base) });
    if cmp == Equal { Ok(base) } else { Err(base + (cmp == Less) as usize) }
}

既然我们发现这个问题了，很简单，我们在 while 循环中判断 cmp == Equal 不就行了？如果相等就直接返回 Ok，否则继续二分去查找。

while size > 1 {
    let half = size / 2;
    let mid = base + half;
    // SAFETY:
    // mid is always in [0, size), that means mid is >= 0 and < size.
    // mid >= 0: by definition
    // mid < size: mid = size / 2 + size / 4 + size / 8 ...
    let cmp = f(unsafe { s.get_unchecked(mid) });
    if cmp == Equal {
        return Ok(base);
    } else if cmp == Less {
        base = mid
    };
    size -= half;
}

为了简洁性，这里（包括后面）都会适当省略重复代码。

嗯，看起来逻辑上没问题，单测也跑通过了，提交一个 PR，我们暂且叫它优化(1)。没过几天 dtolnay review 了我的 PR 并回复了：Would you be able to put together a benchmark assessing the worst case impact? The new implementation does potentially 50% more conditional branches in the hot loop.

确实，Rust 标准库对性能要求非常高，我们必须要有足够多 case 对新旧版本做 benchmark 对比，尽可能避免新的版本导致性能上的 regression。这是当时我做的 benchmark 数据：

// 标准库的实现
test slice::binary_search_l1           ... bench:          59 ns/iter (+/- 4)
test slice::binary_search_l1_with_dups ... bench:          59 ns/iter (+/- 3)
test slice::binary_search_l2           ... bench:          76 ns/iter (+/- 5)
test slice::binary_search_l2_with_dups ... bench:          77 ns/iter (+/- 17)
test slice::binary_search_l3           ... bench:         183 ns/iter (+/- 23)
test slice::binary_search_l3_with_dups ... bench:         185 ns/iter (+/- 19)

// 新版实现
test slice::binary_search_l1           ... bench:          58 ns/iter (+/- 2)
test slice::binary_search_l1_with_dups ... bench:          37 ns/iter (+/- 4)
test slice::binary_search_l2           ... bench:          76 ns/iter (+/- 3)
test slice::binary_search_l2_with_dups ... bench:          57 ns/iter (+/- 6)
test slice::binary_search_l3           ... bench:         200 ns/iter (+/- 30)
test slice::binary_search_l3_with_dups ... bench:         157 ns/iter (+/- 6)

可以看出来在 with_dups 模式（即重复元素较多）下，新的实现有很明显的提升，但是 l3 级别的普通模式性能反而要差很多。可能的原因正如 dtolnay 所说的 The new implementation does potentially 50% more conditional branches in the hot loop。那 conditional branches 具体是什么？为什么它在热循环中如此关键？这里引入这篇文章的第一个知识点：分支预测。

分支预测(Branch prediction)

分支预测 (branch prediction) 是现代 CPU 为了加快指令并行化速度在碰到分支时提前预测下一个可能执行的分支的一种技术。 CPU 中一般都内置专门的分支预测器 (Branch predictor)。强烈推荐先阅读 Stackoverflow 这个高赞回答 Why is processing a sorted array faster than processing an unsorted array?，里面比较清晰易懂的解释了分支预测是什么以及对性能带来的影响。关于分支预测完全可以写一篇专门的文章介绍了，我这里只把我学到的知识总结一下。

分支

首先我们要了解一下分支)到底是指什么？在高级语言层面，很显然分支就是 if/else/else if，goto 或者 switch/match 这种语句。他们会转换成汇编代码中的 jump 指令。比如 x86 汇编的各种 j 开头的 jump 指令：

指令	作用
jmp	Always jump
je	Jump if cmp is equal
jne	Jump if cmp is not equal
jg	Signed > (greater)
jge	Signed >=
jl	Signed < (less than)
jle	Signed <=
ja	Unsigned > (above)
jae	Unsigned >=
jb	Unsigned < (below)
jbe	Unsigned <=
jecxz	Jump if ecx is 0
jc	Jump if carry: used for unsigned overflow, or multiprecision add
jo	Jump if there was signed overflow

比如我们随便写一段包含 if/else 逻辑的代码，编译之后的汇编代码中就会包含类似的 jump 指令：

#![allow(unused_assignments)]
pub fn main() {
  // 接收用户从命令行中输入的参数
  let mut a: usize = std::env::args().nth(1).unwrap().parse().unwrap_or_default();
  if a > 42 { 
    a = 1;
  } else {
    a = 0;
  }
}

这段代码逻辑这么写主要是为了保持汇编指令的尽量简单。这里是对应的汇编代码，只保留了跟 if/else 有关的部分，完整的代码链接在这里：https://rust.godbolt.org/z/ahcKcK1Er。

.LBB99_7:
        cmp     qword ptr [rsp + 56], 42 ; if a > 42
        jbe     .LBB99_10
        mov     qword ptr [rsp + 56], 1  ; a = 1
        jmp     .LBB99_11
.LBB99_10:
        mov     qword ptr [rsp + 56], 0  ; a = 0
.LBB99_11:
        add     rsp, 200
        ret

我在代码里面加了几条注释（汇编里面用分号注释）表明了该条指令对应的 Rust 代码，可以看出来 jbe 指令会判断是否跳转到 .LBB99_10 还是不跳转继续执行下面的 mov。

了解了分支是什么之后还不够，我们依然不知道具体是为啥 CPU 需要做分支预测。接下来我们需要了解一下另外一个概念：指令流水线。

指令流水线(instruction pipelining)

指令流水线是从 instruction pipelining 翻译过来的一个名词，主要是指为了提高单个处理器指令处理效率的一种技术，早在上个世纪 70 年代的芯片就有这种技术了。

CPU 处理一条指令一般要分为几个步骤：

取指令(Instruction Fetch)
解指令(Instruction Decode)
执行指令 (Execute)
回写结果到寄存器 (Register write back)

这非常类似工厂生产某件需要多道工序的商品一样。想象一下，如果工厂每次都是完整的按照工序把第一件商品生产出来之后再进行同样的步骤生产下一件商品的话，这个生产速度得多慢！所以 19 世纪人类就诞生了工业化的流水线，把所有这些工序分解并行化。第一件商品在工序(2)的时候，丝毫不影响第二件商品进入工序(1)。指令也完全可以这样，CPU 可以把指令执行过程流水线化，把不同的指令执行步骤分给不同的逻辑门 (logic stage)处理，第一条指令进入解指令阶段的时候，第二条指令就可以进入取指令阶段了。

Wikipedia 上的这张图可以帮助理解（图中文字颜色为黑色，推荐用 Light 主题查看）。

了解前面的这些概念之后，我们来看一下为什么 CPU 需要做分支预测？

为什么需要分支预测？

指令流水线会按照工厂流水线一样执行指令，这其中也包括前面讲的 jump 指令。而 jump 指令有一个问题就是它需要知道下一个时钟周期该跳转还是不跳转，而这需要等前面的判断逻辑执行完了之后才知道。比如上面的例子 cmp 判断完之后，jump 指令才能决定是跳转到 .LBB99_10 部分，还是不跳转继续执行下去。但是 CPU 指令流水线才不会等，否则白白的浪费一个时钟周期。所以人们发明了一种办法来避免出现这种问题，这就是分支预测。

CPU 的分支预测器会提前预测这条 jump 指令可能会跳转的到哪个分支，然后把预测的那条分支放到流水线中去执行。如果预测正确，CPU 可以继续执行后面的指令；如果预测失败了(branch misprediction)，那只能丢弃刚刚执行的分支结果，重新切换到正确的分支执行。可以看到，如果出现过多的预测失败，分支预测反而很影响性能。不过现在 CPU 的分支预测器经过这么多年的发展已经越来越先进了，人们会采用各种方式不断提高分支预测器的预测准确率，详细可以查看 Wikipedia 的 Branch_predictor 了解更多。

热循环中避免分支预测

虽然现代 CPU 都有分支预测器，但我们在软件层面依然要尽量避免发生分支预测，特别是在热循环中。最常用的优化方法就是避免在循环中写 if/else 语句，即 branchless code。标准库中有大量这种 branchless code 的案例来优化性能，比如 std::collection::Filter 的 count() 方法。

pub struct Filter<I, P> {
    iter: I,
    predicate: P,
}

impl<I: Iterator, P> Iterator for Filter<I, P>
where
    P: FnMut(&I::Item) -> bool,
{
    type Item = I::Item;

    // this special case allows the compiler to make `.filter(_).count()`
    // branchless. Barring perfect branch prediction (which is unattainable in
    // the general case), this will be much faster in >90% of cases (containing
    // virtually all real workloads) and only a tiny bit slower in the rest.
    //
    // Having this specialization thus allows us to write `.filter(p).count()`
    // where we would otherwise write `.map(|x| p(x) as usize).sum()`, which is
    // less readable and also less backwards-compatible to Rust before 1.10.
    //
    // Using the branchless version will also simplify the LLVM byte code, thus
    // leaving more budget for LLVM optimizations.
    #[inline]
    fn count(self) -> usize {
        #[inline]
        fn to_usize<T>(mut predicate: impl FnMut(&T) -> bool) -> impl FnMut(T) -> usize {
            move |x| predicate(&x) as usize
        }

        self.iter.map(to_usize(self.predicate)).sum()
    }
}

标准库的 Filter 类型在实现 Iterator 的时候重写了 count() 方法。想想如果我们没有意识到分支预测这个问题的情况下可能会这么实现：

// Bad
#[inline]
fn count(self) -> usize {
    let sum = 0;

    self.iter.for_each(|x| {
        if self.predicate(x) {
            sum += 1;
        }
    });

    sum
}

但这种实现在循环中有一个 if 语句，导致 CPU 需要进行大量的分支预测，而这些分支预测几乎都是随机的，CPU 很难根据历史记录提高预测的准确度，导致性能会比较低。而标准库的实现完全是 branchless 的，不仅性能好很多，而且也能方便 LLVM 做更多优化。

关于怎样写好 branchless code 来优化性能又是另一个值得专门讨论的主题了，网上也有大量资料可以学习。但是 branchless code 会牺牲不少代码可读性，并不建议盲目的使用。

branchless code 的额外好处是还能帮助避免遭受旁路攻击(英文 timing attack 或者 side-channel attack)。参考：https://en.wikipedia.org/wiki/Timing_attack。

继续回到我们刚才的那个 PR。我们的版本比标准库旧的版本在某些 case 下性能要低确实跟分支预测有关，因为我们的代码多了一种分支需要预测。

为了方便大家对比，我把汇编的截图贴到下面。我们只需要关注我标记文字的那几个颜色就可以。很容易看出来新版实现多了一个 jne 的跳转指令，导致 CPU 需要多做一次分支预测。

申明：启用 -O 参数之后汇编指令会被优化得更精简，这里没有启用 -O 是为了对应到每一行源码方便对比。

标准库的汇编截图

优化(1)的汇编截图

需要注意的是 jmp 指令是直接跳转，不需要进行分支预测。感兴趣的朋友可以看一下我在 Godbolt 上的对比：https://rust.godbolt.org/z/8dGbY8Pe1。这个网站是神器，强烈推荐！

优化（2）

所以我推测原作者实现标准库的 binary_search_by() 的时候不考虑 O(1) 最好时间复杂度的可能原因之一就是为了避免多余的分支预测。因为你要想 O(1) 就避免不了提前 return，要想提前 return 你就避免不了分支判断。那怎么办呢？PR 里面有一个大牛 tesuji 提供了一种思路：既然我们避免不了分支预测，那我们尽量帮助 CPU 更好的做好分支预测吧。于是我采用了他的方案，具体 commit 在这里，我们暂且叫它优化(2)：

pub fn binary_search_by<'a, F>(&'a self, mut f: F) -> Result<usize, usize>
where
    F: FnMut(&'a T) -> Ordering,
{
    let mut left = 0;
    let mut right = self.len();
    while left < right {
        // never overflow because `slice::len()` max is `isize::MAX`.
        let mid = (left + right) / 2;
        // SAFETY: the call is made safe by the following invariants:
        // - `mid >= 0`
        // - `mid < size`: `mid` is limited by `[left; right)` bound.
        let cmp = f(unsafe { self.get_unchecked(mid) });
        if cmp == Less {
            left = mid + 1;
        } else if cmp == Greater {
            right = mid;
        } else {
            return Ok(mid);
        }
    }
    Err(left)
}

优化(2)的代码明显比标准库和优化(1)的代码更容易理解，再看一下它的生成的汇编代码。

可以看出来依然是两条 jne 指令，所以非重复模式下的性能可能还是没有标准库的高，但是确实比优化(1)的性能要好很多。过了几天 libs 组的 m-ou-se 回复了评论。她也做了 benchmark，发现对于原生类型比如 u32 下 l1 级别的数据量依然比标准库慢，但是那些需要更多时间比较的类型（比如 String）的情况下，新的实现在所有 case 下性能都要优于标准库的实现。后面大家又讨论了许多，最终 m-ou-se 决定先跑一个 crater 测试，先验证一下这个 PR 对 crates.io 上所有的 crate 影响面大不大。最终 library 团队会议一致同意可以 merge 这个 PR。

关于 crater 测试：

crater 大概就是针对整个 crates.io 上所有的 crate 给要测试的编译器版本（比如我的 PR ）跑一次测试，看这个改动对线上所有 crate 影响大不大。crates.io 上超过5万个 crate，一般跑一次 crater 需要将近一周的时间。我的这个 crater 跑完之后就是因为没有对已发布的 crate 造成什么很大的影响，所以官方才愿意合并。

From m-ou-se:

"We discussed this PR in a recent library team meeting, in which we agreed that the proposed behaviour (stopping on Equal) is preferrable over optimal efficiency in some specific niche cases. Especially considering how small most of the differences are in the benchmarks above."

"The breakage in the crater report looks reasonably small. Also, now that partition_point is getting stabilized, there's a good alternative for those who want the old behaviour of binary_search_by. So we should go ahead and start on getting this merged. :)"

整数溢出问题

然而 scottmcm 又指出了另外一个问题：

// never overflow because `slice::len()` max is `isize::MAX`.
let mid = (left + right) / 2;

这行代码在零大小类型(Zero Sized Type，简称 ZST)下却可能会 overflow! 我们来分析一下为什么。

slice::len() 的返回值是 usize 类型，但是对于非零大小的类型(non-ZST)，slice::len() 的值最大也只能是 isize::MAX。所以就像注释上写的那样 (isize::MAX + isize::MAX) / 2 是不可能超过 usize::MAX 的，所以不会发生 overflow。但是对于 ZST 类型就不一样了，如果 slice 里面所有元素都是零大小的（比如 ()），那这个 slice 的长度完全可以达到 usize::MAX。虽然对于 [(); usize::MAX].binary_search(&()) 这种情况我们会在 O(1) 的时间复杂度上找到结果并马上返回，但是如果我们这么写 b.binary_search_by(|_| Ordering::Less)，它就发生整数溢出了。

为什么 `slice::len()` 对于 non-ZST 最大值是 `isize` 呢？

最简单直接的原因是我们不能构造一个所有元素都为 non-ZST 并且长度为 usize::MAX 的数组或 slice，编译器在编译阶段直接会报错。比如以最简单的只占 1 个字节的 bool 类型为例，[bool; usize::MAX] 的大小将等于 std::mem::size_of::<bool>() * usize::MAX, 这是一个很大的数字了，整个计算机地址空间都不够。

fn main() {
    assert_eq!(std::mem::size_of::<bool>(), 1);
    // error: values of the type `[bool; 18446744073709551615]` are too big 
    // for the current architecture
    let _s = [true; usize::MAX];
}

但是对于 ZST 是可以的，因为 std::mem::size_of::<()>() * usize::MAX 依然是零。

fn main() {
    assert_eq!(std::mem::size_of::<()>(), 0);
    let s = [(); usize::MAX];
    assert_eq!(s.len(), usize::MAX);
}

不过上面的解释依然不够严谨，比如 std::mem::size_of::<bool>() * isize::MAX 也依然是一个很大的数字呀，为啥 isize::MAX 就可以？根本原因在于 Rust 指针寻址最大 offset 只允许 isize::MAX，至于为什么是 isize::MAX，std::pointer::offset() 的文档有解释。另外也可以看一下 std::slice::from_raw_parts() 的文档。而对于 ZST 的类型，编译器会做优化，它压根不需要寻址，所以最大大小可以是 usize::MAX。

最终版本

意识到整数溢出的问题之后，解决方式也比较简单，这是我当时的提交，并且还增加了针对 overflow 的单元测试。

pub fn binary_search_by<'a, F>(&'a self, mut f: F) -> Result<usize, usize>
    where
        F: FnMut(&'a T) -> Ordering,
    {
        let mut size = self.len();
        let mut left = 0;
        let mut right = size;
        while left < right {
            let mid = left + size / 2;

            // SAFETY: the call is made safe by the following invariants:
            // - `mid >= 0`
            // - `mid < size`: `mid` is limited by `[left; right)` bound.
            let cmp = f(unsafe { self.get_unchecked(mid) });
            // The reason why we use if/else control flow rather than match
            // is because match reorders comparison operations, which is 
            // perf sensitive.
            // This is x86 asm for u8: https://rust.godbolt.org/z/8Y8Pra.
            if cmp == Less {
                left = mid + 1;
            } else if cmp == Greater {
                right = mid;
            } else {
                return Ok(mid);
            }

            size = right - left;
        }
        Err(left)
    }

#[test]
fn test_binary_search_by_overflow() {
    let b = [(); usize::MAX];
    assert_eq!(b.binary_search_by(|_| Ordering::Equal), Ok(usize::MAX / 2));
    assert_eq!(b.binary_search_by(|_| Ordering::Greater), Err(0));
    assert_eq!(b.binary_search_by(|_| Ordering::Less), Err(usize::MAX));
}

我们确实应该尽量避免写 let mid = (left + right) / 2 这种很容易发生整数溢出的代码，换成 let mid = left + size / 2 这种，可以避免发生 overflow。

另外还有人问为什么这里使用 if/else 而不是 match 语句？我们查看两个版本的汇编指令后发现 match 版本生成的汇编代码不仅指令更多而且还重排了 cmp 指令的顺序，性能似乎更差。理论上这两个版本生成的汇编指令应该可以做到一致的，我暂时没有深究原因为什么 match 版本的汇编会差一些，其他读者感兴趣可以研究一下。

总结

表面波澜不惊，实则暗流涌动。一个看起来十分简单的 PR 里面其实涉及到很多内容。学无止境，笔者通过这个 PR 收获了很多，现在分享出来同时也希望能够激励更多国内开发者参与进来。Rust 社区文化是如此开放和包容，任何人只要发现有可以改进的地方都可以随时给 Rust 仓库提交 PR 或 issue，这样做不仅能帮助 Rust 越来越好，你自己也会得到巨大的成长和收获！

Rust 的 Pin 与 Unpin

2020-11-20T00:00:00Z

2019年2月28号，Rust 1.33版发布，增加了新的pinning API，主要包括这几个：

std::pin::Pin
std::marker::Unpin
std::marker::PhantomPinned
impl !Unpin for T

刚开始接触这些概念的时候感觉特别绕，有点难理解透彻。网上也有不少讲Pin和Unpin的文章，但总感觉讲得不是特别清楚。直接去看std::pin模块的文档理解起来也挺有难度的。所以这篇文章我将尝试由浅入深的梳理一下Pin和Unpin，希望能帮助大家理解这些概念。

概念

我们先看一下Pin官方文档上的定义：

/// A pinned pointer.
///
/// This is a wrapper around a kind of pointer which makes that pointer "pin" its
/// value in place, preventing the value referenced by that pointer from being moved
/// unless it implements [`Unpin`].
#[stable(feature = "pin", since = "1.33.0")]
#[lang = "pin"]
#[fundamental]
#[repr(transparent)]
#[derive(Copy, Clone)]
pub struct Pin<P> {
    pointer: P,
}

#[stable(feature = "pin", since = "1.33.0")]
impl<P: Deref> Deref for Pin<P> {
    type Target = P::Target;
    fn deref(&self) -> &P::Target {
        Pin::get_ref(Pin::as_ref(self))
    }
}

#[stable(feature = "pin", since = "1.33.0")]
impl<P: DerefMut<Target: Unpin>> DerefMut for Pin<P> {
    fn deref_mut(&mut self) -> &mut P::Target {
        Pin::get_mut(Pin::as_mut(self))
    }
}

我先来从宏观层面解读一下。Pin是一个这样的智能指针，他内部包裹了另外一个指针P，并且只要P指针指向的内容（我们称为T）没有实现Unpin，则可以保证T永远不会被移动（move）。Pin这个单词也很形象的表示Pin就像钉子一样可以把T钉住。所以Pin一般来说用Pin<P<T>>这种方式表示（P是Pointer的缩写，T是Type的缩写）。这个定义初看有点绕，我们来划几个重点：

Pin自身是一个智能指针。为什么呢？因为他impl了Deref和DerefMut。
Pin包裹的内容只能是指针，不能是其他普通类型。比如Pin<u32>就没有意义。
Pin具有“钉住”T不能移动的功能，这个功能是否生效取决于T是否impl Unpin。简单的说，如果T实现了Unpin，Pin的“钉住”功能完全失效了，这时候的Pin<P<T>>就等价于P<T>。
Unpin是一个auto trait，编译器默认会给所有类型实现Unpin。唯独有几个例外，他们实现的是!Unpin。这几个例外是PhantomPinned，编译器为async/await desugar之后生成的impl Future的结构体。
所以Pin<P<T>>默认情况下的“钉住”功能是不生效的，只针对上面说的这几个impl !Unpin的情况生效。

看了这几条可能还有点懵，没关系，我们开始逐条剖析。首先要搞清楚的是到底什么是move以及为什么有些情况我们要防止move发生？

到底什么是move？

根据官方定义：所有权转移的这个过程就是move。我们先看一个大家都非常熟悉的例子：

fn main() {
  let mut s1 = String::from("Hello");
  let s2 = s1; // s1的所有权转移给了s2，这里发生了move
  // let s3 = s1; // s1的所有权以及转移走了，不能再move，否则会报错：error[E0382]: use of moved value: `s1`
}

基本概念这里不多解释了，我们需要搞明白的是let s2 = s1;这一行到底发生了什么事情。

借用了TRPL书上的这张图。s1和s2两个变量都是在栈上分配内存，字符串“Hello”是在堆上分配内存，其中ptr字段就是指向该字符串的指针。move发生的时候编译器会在栈上开辟一块新内存s2，然后原封不动把s1栈上的内容拷贝到s2，随即立马让原s1的内存失效。

再看一个move的列子：

fn main() {
    let mut x = String::from("xxx");
    let mut y = String::from("yyy");

    std::mem::swap(&mut x, &mut y);

    assert_eq!("yyy", &x);
    assert_eq!("xxx", &y);
}

我们通过std::mem::swap()方法交换了两个可变借用&mut的内容，这里也发生了move。

像这两种move在Rust里面很稀松平常，使用起来丝毫不会引发什么问题。那到底是什么情况需要防止move的发生呢？

还真有，那就是自引用结构体！

自引用结构体的move

自引用结构体（Self-Referential Structs）是一个这个样的结构体，它内部某个成员是对另外一个成员的引用。比如这样：

struct Test<'a> {
    a: String,
    b: &'a String,
}

fn main() {
    let a = String::from("Hello");
    let _test = Test { a, b: &a };
//    let _test = Test { a, b: &a };
//  |                        -     ^^ value borrowed here after move
//  |                        |
//  |                        value moved here
}

但事实上我们没办法通过Safe Rust构造一个像Test这样的自引用结构体，Rust目前对自引用结构体支持还很不完善。只能变通一下使用指针：

#[derive(Debug)]
struct Test {
    a: String,
    b: *const String, // 改成指针
}

impl Test {
    fn new(txt: &str) -> Self {
        Test {
            a: String::from(txt),
            b: std::ptr::null(),
        }
    }

    fn init(&mut self) {
        let self_ref: *const String = &self.a;
        self.b = self_ref;
    }

    fn a(&self) -> &str {
        &self.a
    }

    fn b(&self) -> &String {
        unsafe {&*(self.b)}
    }
}

我们来试一下这个自引用结构体的move：

fn main() {
    let mut test1 = Test::new("test1");
    test1.init();
    let mut test2 = Test::new("test2");
    test2.init();

    println!("a: {}, b: {}", test1.a(), test1.b());
    // 使用swap()函数交换两者，这里发生了move
    std::mem::swap(&mut test1, &mut test2);
    test1.a = "I've totally changed now!".to_string();
    println!("a: {}, b: {}", test2.a(), test2.b());
}

这是打印结果：

a: test1, b: test1
a: test1, b: I've totally changed now!

有没有发现，出问题了！问题出在哪？原因是Test结构体中的字段b是一个指向字段a的指针，它在栈上存的是字段a的地址。通过swap()函数交换两个Test结构体之后，字段a,b分别移动到对方的内存区域上，但是a和b本身的内容没有变。也就是指针b依然指向的是原来的地址，但是这个地址现在已经属于另外一个结构体了！这不仅不是自引用结构体了，更可怕的是这个指针可能导致更危险的问题，这是Rust决不允许出现的！👇下面这张图可以帮助理解：

更关键的是Rust的Generator和async/await这一套都是基于自引用结构体实现的。如果不能从根源上解决这个问题，Rust号称的Memory Safe的根基就完全动摇了。

更多关于async/await的原理，强烈推荐阅读这两本书：

https://rust-lang.github.io/async-book

https://cfsamson.github.io/books-futures-explained

所以我们来找一下导致这个问题的根源，然后想办法从根源上解决它！

根源是什么？

我们发现上面的例子最关键的一行代码是std::mem::swap(&mut test1, &mut test2)，就是它导致了我们自引用结构体失效引发了内存安全问题。所以我们是不是只要避免这个swap()函数应用到我们自引用结构体上就行？可是怎么去避免呢？我们来看一下swap()方法的定义：

#[inline]
#[stable(feature = "rust1", since = "1.0.0")]
pub fn swap<T>(x: &mut T, y: &mut T) {
    // SAFETY: the raw pointers have been created from safe mutable references satisfying all the
    // constraints on `ptr::swap_nonoverlapping_one`
    unsafe {
        ptr::swap_nonoverlapping_one(x, y);
    }
}

它的参数要求是可变借用&mut，所以只要我们想办法让Safe Rust下不暴露可变借用即可！

还是以Test为例，它自身没办法限制自己不能可变借用，因为我们直接用&mut Test{...}就可以轻松拿到。那从标准库中去找找，Box<T>呢？先不考虑它性能问题，我们把结构体T包裹在Box中，看Box能不能保证不暴露&mut T出去。看一下API文档，很遗憾不能。Box::leak()返回值就是&mut T，更甚者Box impl了DerefMut，就算不用leak()我们也可以通过* &mut Box<T>解引用轻松拿到&mut T！

不用找了，在Pin之前的标准库中确实没有这样的API能够防止在Safe Rust下不暴露&mut T。

所以，接下来是该Pin登场的时候了！

Pin闪亮登场

我们找到了问题的根源在哪，Pin就是从根源上解决这个问题的。现在我们很清晰了，似乎是不是可以用一句话概括：Pin就是一个不会让你在Safe Rust暴露可变借用&mut的智能指针?

答案是：不全正确。这就是Pin概念起初让大家一脸懵逼的地方。下面让Pin自己来解答大家的疑惑，Pin说：“你们不是想让我保证被我包裹的指针P<T>永远钉住不让move吗？我可以答应，但我有一个原则。那就是我永远不能钉住持有通行证的朋友，这张通行证就是Unpin。如果没有这张通行证，请放心，我会把你钉得死死的！”

举个例子。比如我是Pin，你是P<T>，如果你impl了Unpin，我会提供两种办法让你在Safe Rust下拿到&mut T：

第一种，使用：Pin::get_mut()

impl<'a, T: ?Sized> Pin<&'a mut T> {
    #[stable(feature = "pin", since = "1.33.0")]
    #[inline(always)]
    pub fn get_mut(self) -> &'a mut T where T: Unpin {
        self.pointer
    }
}

第二种，我impl了DerefMut，你可以解引用拿到&mut T

#[stable(feature = "pin", since = "1.33.0")]
impl<P: DerefMut<Target: Unpin>> DerefMut for Pin<P> {
    fn deref_mut(&mut self) -> &mut P::Target {
        Pin::get_mut(Pin::as_mut(self))
    }
}

可rustc爸爸太宽容了，他默认给你们所有类型发了通行证（都实现了Unpin）！搞得我都几乎快要失业了！

#[lang = "unpin"]
pub auto trait Unpin {}

#[stable(feature = "pin", since = "1.33.0")]
impl<'a, T: ?Sized + 'a> Unpin for &'a T {}

#[stable(feature = "pin", since = "1.33.0")]
impl<'a, T: ?Sized + 'a> Unpin for &'a mut T {}

#[stable(feature = "pin_raw", since = "1.38.0")]
impl<T: ?Sized> Unpin for *const T {}

#[stable(feature = "pin_raw", since = "1.38.0")]
impl<T: ?Sized> Unpin for *mut T {}

唯一让我欣慰的是，他给我留了一个叫PhantomPinned的小伙伴。别看他名字很奇怪，他可是我很喜欢的得力助手！因为他实现的是!Unpin！

#[stable(feature = "pin", since = "1.33.0")]
#[derive(Debug, Copy, Clone, Eq, PartialEq, Ord, PartialOrd, Hash)]
pub struct PhantomPinned;

#[stable(feature = "pin", since = "1.33.0")]
impl !Unpin for PhantomPinned {}

rustc爸爸还说，你们如果想“改邪归正”去掉Unpin也可以，有两种办法：

使用PhantomPinned。有了它，rustc爸爸不会让你实现Unpin。

use std::marker::PhantomPinned;

#[derive(Debug)]
struct Test {
   a: String,
   b: *const String,
   _marker: PhantomPinned,
}

给自己手动impl !Unpin。前提是你要使用nightly版本，并且需要引入#![feature(negative_impls)]：

#![feature(negative_impls)]
#[derive(Debug)]
struct Test {
    a: String,
    b: *const String,
}

impl !Unpin for Test {}

满足以上任意两个条件之一的话，我就会保证你没办法在Safe Rust下拿到可变借用&mut T（不信你去翻翻我的API），拿不到&mut T你就没办法作用到std::mem::swap()上，也就是说你被我钉住了！你以为rustc爸爸给我施了魔法么？你错了，我的工作原理就是这么简单！感谢Rust世界丰富而强大的类型系统，我的其他兄弟Sync, Send也是这样，我们都没有所谓的魔法！

当然我还是提供了一个unsafe的get_unchecked_mut()，不管你有没有实现Unpin，你都可以通过调用这个方法拿到&mut T，但是你需要遵守Pin的契约（参考下面），否则出了什么问题后果自负！

impl<'a, T: ?Sized> Pin<&'a mut T> {
    #[stable(feature = "pin", since = "1.33.0")]
    #[inline(always)]
    pub unsafe fn get_unchecked_mut(self) -> &'a mut T {
        self.pointer
    }
}

Pin的契约：

对于Pin<P<T>>,

如果P<T>符合Unpin，那P<T>从被Pin包裹到被销毁，都要一直保证P<T>不被钉住

如果P<T>符合!Unpin，那P<T>从被Pin包裹到被销毁，都要一直保证P<T>被钉住

通过以上Pin的自述，我们再用一句话来总结：如果你实现了Unpin，Pin可以让你在Safe Rust下拿到&mut T，否则会把你在Safe Rust下钉住（也就是拿不到&mut T）。

接下来我们使用Pin来修复一下上面自引用结构体的问题。

如何构造一个Pin

首先我们要梳理清楚怎样把P<T>用Pin包裹起来，也就是怎样构造一个Pin。查看文档会发现主要有这几种方式：

Pin::new()

impl<P: Deref<Target: Unpin>> Pin<P> {
    #[stable(feature = "pin", since = "1.33.0")]
    #[inline(always)]
    pub fn new(pointer: P) -> Pin<P> {
        // Safety: the value pointed to is `Unpin`, and so has no requirements
        // around pinning.
        unsafe { Pin::new_unchecked(pointer) }
    }
}

如果你的P指向的T是Unpin的话，你可以安全的调用Pin::new()构造一个Pin。可以看到它底层实际上是调用unsafe的Pin::new_unchecked()，之所以Pin::new()是安全的，是因为Unpin的情况下Pin的”钉住“效果是不起作用的，跟正常的指针一样了。

Pin::new_unchecked()

impl<P: Deref> Pin<P> {
    #[stable(feature = "pin", since = "1.33.0")]
    #[inline(always)]
    pub unsafe fn new_unchecked(pointer: P) -> Pin<P> {
        Pin { pointer }
    }
}

这个方法很简单，但它是unsafe的。标为unsafe的原因是编译器没办法保证使用者后续操作一定遵守Pin的契约。只要有存在违反契约的可能性，就必须用unsafe标记，因为这是使用者的问题，编译器没办法保证。如果使用者通过Pin::new_unchecked()构造一个Pin<P<T>>之后Pin的生命周期结束了，但P<T>依然存在，则后续操作依然可能被move，造成内存不安全。

use std::mem;
use std::pin::Pin;

fn move_pinned_ref<T>(mut a: T, mut b: T) {
    unsafe {
        let p: Pin<&mut T> = Pin::new_unchecked(&mut a);
        // This should mean the pointee `a` can never move again.
    }
    mem::swap(&mut a, &mut b);
    // The address of `a` changed to `b`'s stack slot, so `a` got moved even
    // though we have previously pinned it! We have violated the pinning API contract.
}

其他

包括Box::pin(), Rc::pin()和Arc::pin()等，底层都是调用上面的Pin::new_unchecked()，不再阐述。

Pin的应用

Pin可以分为栈上还是堆上，取决于你要Pin的那个指针P是在栈上还是堆上。比如Pin<&mut T>是栈上，Pin<Box<T>>是在堆上。

Pin到栈上

use std::pin::Pin;
use std::marker::PhantomPinned;

#[derive(Debug)]
struct Test {
    a: String,
    b: *const String,
    _marker: PhantomPinned,
}

impl Test {
    fn new(txt: &str) -> Self {
        Test {
            a: String::from(txt),
            b: std::ptr::null(),
            _marker: PhantomPinned, // This makes our type `!Unpin`
        }
    }

    fn init<'a>(self: Pin<&'a mut Self>) {
        let self_ptr: *const String = &self.a;
        let this = unsafe { self.get_unchecked_mut() };
        this.b = self_ptr;
    }

    fn a<'a>(self: Pin<&'a Self>) -> &'a str {
        &self.get_ref().a
    }

    fn b<'a>(self: Pin<&'a Self>) -> &'a String {
        unsafe { &*(self.b) }
    }
}

pub fn main() {
    let mut test1 = unsafe { Pin::new_unchecked(&mut Test::new("test1")) };
    Test::init(test1.as_mut());

    let mut test2 = unsafe { Pin::new_unchecked(&mut Test::new("test2")) };
    Test::init(test2.as_mut());

    println!("a: {}, b: {}", Test::a(test1.as_ref()), Test::b(test1.as_ref()));
    std::mem::swap(test1.get_mut(), test2.get_mut());
    println!("a: {}, b: {}", Test::a(test2.as_ref()), Test::b(test2.as_ref()));
}

我们尝试把&mut Test钉在栈上，然后尝试去调用get_mut()作为参数传给std::mem::swap()，发现编译不通过。Rust编译器从编译阶段就阻止我们去犯错了。

  |     std::mem::swap(test1.get_mut(), test2.get_mut());
  |                          ^^^^^^^ within `Test`, the trait `Unpin` is not implemented for `PhantomPinned`
  |

Pin到堆上

use std::pin::Pin;
use std::marker::PhantomPinned;

#[derive(Debug)]
struct Test {
    a: String,
    b: *const String,
    _marker: PhantomPinned,
}

impl Test {
    fn new(txt: &str) -> Pin<Box<Self>> {
        let t = Test {
            a: String::from(txt),
            b: std::ptr::null(),
            _marker: PhantomPinned,
        };
        let mut boxed = Box::pin(t);
        let self_ptr: *const String = &boxed.as_ref().a;
        unsafe { boxed.as_mut().get_unchecked_mut().b = self_ptr };

        boxed
    }

    fn a<'a>(self: Pin<&'a Self>) -> &'a str {
        &self.get_ref().a
    }

    fn b<'a>(self: Pin<&'a Self>) -> &'a String {
        unsafe { &*(self.b) }
    }
}

pub fn main() {
    let mut test1 = Test::new("test1");
    let mut test2 = Test::new("test2");

    println!("a: {}, b: {}",test1.as_ref().a(), test1.as_ref().b());
    // std::mem::swap(test1.get_mut(), test2.get_mut());
    // std::mem::swap(&mut *test1, &mut *test2);
    println!("a: {}, b: {}",test2.as_ref().a(), test2.as_ref().b());
}

这里使用Box::pin()把Test钉在了堆上。取消注释任意一行都会编译不通过，因为Test是!Unpin的。

Future

#[stable(feature = "futures_api", since = "1.36.0")]
pub trait Future {
    type Output;
    fn poll(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output>;
}

接下来讲一下Pin目前最重要的一个应用：Future。当初2018年官方异步组引入Pin API的初衷就是为了解决Future内部自引用的问题。因为async/await就是通过Generator实现的，Generator是通过匿名结构体实现的。如果async函数中存在跨await的引用，会导致底层Generator存在跨yield的引用，那根据Generator生成的匿名结构体就会是一个自引用结构体！然后这个自引用结构体会impl Future，异步的Runtime在调用Future::poll()函数查询状态的时候，需要一个可变借用（即&mut Self）。如果这个&mut Self不包裹在Pin里面的话，开发者自己impl Future就会利用std::mem::swap()之类的函数move掉&mut Self！所以这就是Future的poll()必须要使用Pin<&mut Self>的原因。

// 这个async块中存在跨await的借用！
let mut fut = async {
    let to_borrow = String::from("Hello");
    let borrowed = &to_borrow;
    SomeResource::some_task().await;
    println!("{} world!", borrowed);
};

当然还有非常重要的一点不能忘了！Pin只对实现!Unpin的类型才有钉住的效果，这个impl Future的匿名结构体有impl !Unpin吗？当然有，前面说了只有几种特例是默认 !Unpin，这个匿名结构体就是其中之一。

pub const fn from_generator<T>(gen: T) -> impl Future<Output = T::Return>
where
    T: Generator<ResumeTy, Yield = ()>,
{
    #[rustc_diagnostic_item = "gen_future"]
    struct GenFuture<T: Generator<ResumeTy, Yield = ()>>(T);

    // We rely on the fact that async/await futures are immovable in order to create
    // self-referential borrows in the underlying generator.
    impl<T: Generator<ResumeTy, Yield = ()>> !Unpin for GenFuture<T> {}

    impl<T: Generator<ResumeTy, Yield = ()>> Future for GenFuture<T> {
        type Output = T::Return;
        fn poll(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output> {
            // SAFETY: Safe because we're !Unpin + !Drop, and this is just a field projection.
            let gen = unsafe { Pin::map_unchecked_mut(self, |s| &mut s.0) };

            // Resume the generator, turning the `&mut Context` into a `NonNull` raw pointer. The
            // `.await` lowering will safely cast that back to a `&mut Context`.
            match gen.resume(ResumeTy(NonNull::from(cx).cast::<Context<'static>>())) {
                GeneratorState::Yielded(()) => Poll::Pending,
                GeneratorState::Complete(x) => Poll::Ready(x),
            }
        }
    }

    GenFuture(gen)
}

划重点impl<T: Generator<ResumeTy, Yield = ()>> !Unpin for GenFuture<T> {}，只有亲眼所见才能让大家信服。

其他

Pin除了上面这些内容外还有其他几个概念，比如Pin projection, Structural pin和Non-structural pin，笔者自己用的也不多，详细可以看官方文档或查阅其他资料。

futures-rs中还有不少和Pin有关的API，如果深入使用futures-rs的话，不可避免的需要频繁的和Pin打交道。

总结

下面是摘抄自官方Async Book上关于Pin的黄金8条作为总结，这些几乎就是Pin API的全部了。

If T: Unpin (which is the default), then Pin<'a, T> is entirely equivalent to &'a mut T. in other words: Unpin means it's OK for this type to be moved even when pinned, so Pin will have no effect on such a type.

Getting a &mut T to a pinned T requires unsafe if T: !Unpin.

Most standard library types implement Unpin. The same goes for most "normal" types you encounter in Rust. A Future generated by async/await is an exception to this rule.

You can add a !Unpin bound on a type on nightly with a feature flag, or by adding std::marker::PhantomPinned to your type on stable.

You can either pin data to the stack or to the heap.

Pinning a !Unpin object to the stack requires unsafe

Pinning a !Unpin object to the heap does not require unsafe. There is a shortcut for doing this using Box::pin.

For pinned data where T: !Unpin you have to maintain the invariant that its memory will not get invalidated or repurposed from the moment it gets pinned until when drop is called. This is an important part of the pin contract.

2018年Rust异步组的核心成员@withoutboats在他个人博客分享了稳定async/await的整个心路历程，感觉这一路也是充满曲折。比如Pin刚开始还需要区分Pin，PinMut，PinBox等，现在精简到只需要一个Pin就能搞定。还有更早的时候还计划引入一个叫Move的trait来标记该类型是否可以move等等。我这篇文章里面的代码基于1.48版，不确定Pin以后会不会有更新，而且Pin目前还存在一个unsoundness的问题。不管怎样，一切简单优雅的设计背后一定隐藏着复杂和艰辛，感谢Rust官方过去的努力，让我们能够有内存安全、无畏并发和符合人体工程的编程体验！

Rust 未来 Generator 语法探索之 Propane

2020-08-07T00:00:00Z

现状

众所周知，Rust的Generator一直没有稳定，主要原因是Generator仍然有许多设计上的问题没有明确，所以无船同志写了一个名字叫Propane的新crate，旨在nightly上实验性的探索Rust Generator未来语法的可能性。

Propane中文翻译：丙烷，无船同志取名向来看起来比较奇怪，不知道是否有其他用意

目前nightly的generator只能写成闭包的形式（官方称作generator literal），比如这样：

#![feature(generators, generator_trait)]

fn main() {
    let mut generator = || {
        yield 1;
        return "foo"
    };
}

如果你写成这样的话：

#![feature(generators, generator_trait)]

fn fake_generator() -> &'static str {
    yield 1;
    return "foo"
}

fn main() {
    let mut generator = fake_generator;
}

编译器会报E0627 A yield expression was used outside of the generator literal.这个错。也就是目前的generator不支持以函数的方式写。

Propane

前面说了，generator很多语法没有稳定甚至不支持，主要原因还是很多设计理念没有明确，所以Propane这个库先迈出了第一步。

#![feature(generators, generator_trait, try_trait)]

#[propane::generator]
fn fizz_buzz() -> String {
   for x in 1..101 {
      match (x % 3 == 0, x % 5 == 0) {
          (true, true)  => yield String::from("FizzBuzz"),
          (true, false) => yield String::from("Fizz"),
          (false, true) => yield String::from("Buzz"),
          (..)          => yield x.to_string(),
      }
   }
}

fn main() {
    let mut fizz_buzz = fizz_buzz();
    assert_eq!(&fizz_buzz.next().unwrap()[..], "1");
    assert_eq!(&fizz_buzz.next().unwrap()[..], "2");
    assert_eq!(&fizz_buzz.next().unwrap()[..], "Fizz");
    assert_eq!(&fizz_buzz.next().unwrap()[..], "4");
    assert_eq!(&fizz_buzz.next().unwrap()[..], "Buzz");
    assert_eq!(&fizz_buzz.next().unwrap()[..], "Fizz");
    assert_eq!(&fizz_buzz.next().unwrap()[..], "7");

    // yada yada yada
    let mut fizz_buzz = fizz_buzz.skip(90);

    assert_eq!(&fizz_buzz.next().unwrap()[..], "98");
    assert_eq!(&fizz_buzz.next().unwrap()[..], "Fizz");
    assert_eq!(&fizz_buzz.next().unwrap()[..], "Buzz");
    assert!(fizz_buzz.next().is_none());
}

Propane提供了一个generator宏，可以让我们以函数的方式写Generator。当然Propane的主要目的是为了验证两个主要的设计理念是否合理：

1) 默认返回Iterator；return关键字可以终止generator，但只支持返回(); generator中的?表达式的默认行为和普通函数有差别

用Propane的generator宏标记的函数是一个返回impl Iterator的生成器，生成器中依然可以使用return关键字来终止，但是不能返回其他类型的值，只支持返回()。

生成器中支持?表达式，但是与普通函数中不同的是，如果生成器yield是一个Result类型，当?表达式碰到错误情况时会把错误yield出去，而不是return出去。然后在下一次resume直接退出生成器。

2) 不支持自引用(Self-referential)

async/await语法稳定的时候为了解决自引用的问题花了很大的心思设计Pin和Unpin等概念。如果Generator默认返回迭代器Iterator的话，我们依然会碰到了自引用的问题。因为Iterator::next在1.0就稳定了，我们不可能再去修改它的API来让迭代器支持自引用。如果不考虑性能，目前最简单粗暴的方法是可以把Generator的每个state装箱到堆上。

当然如果我们不支持自引用，就可以让generator支持零开销（zero cost），而且无船同志也大胆的推测（hypothesis）：也许我们确实不需要一个支持自引用的Generator。

最后，无船同志强调，这几个理念仅仅是实验性的，而且也有可能是一次失败的尝试。

以上是我了解完Propane之后结合无船的博客整理的文章，Propane的代码也很简洁，大家可以去Github查看。

链接：Propane: an experimental generator syntax for Rust

Moonlit Sailor - 我的年度乐队

2019-01-06T00:00:00Z

网易云音乐前几天发布了2018年年度听歌报告，毫无意外Moonlit Sailor成为了我的2018年度乐队！

2018年初不经意在一个后摇歌单里听到一首名叫《Hope》的曲子，我的心瞬间被它的编曲、旋律、乐器声所俘获。

天哪，如此好听！跟大多数后摇充满阴暗抑郁的一面截然不同，这首曲子正如曲名，点燃希望，温暖人心。单曲循环不知多少遍，甚至想把它据为己有不愿分享，这完全是我苦苦寻求的音乐啊。

如获至宝之后一发不可收拾，我听了他们所有的专辑、所有的曲子，没想到的是他们每一首曲子都非常符合我的品位。

整整一年时间里，他们的音乐一直陪伴着我，给我带来温暖，让我乐观积极，给我莫大动力！我很感谢他们，为此我必须要写一篇博客记录一下这个来自瑞典的年轻后摇乐队！

Devoid of all lyrics, the music alone speaks for itself… and it speaks volumes. -- Deep Elm Records

Moonlit Sailor简介

Moonlit Sailor 于2006年成立于瑞典西南的一个人口十万左右的城市Borås（布罗斯），乐队成员四个人，分为别为 Joakim Wiik (键盘/吉他)，Oscar Gulbrandsen (吉他)，Adam Törnblad (架子鼓/吉他/钢琴)和 Markus Rundlöf (贝斯)。组建乐队的时候他们四个才16~18岁。乐队的成员都是在小学时候就认识了的最好的朋友，他们其中三个人在12岁的时候就开始学怎样组建乐队玩音乐，几年之后直到第四个小伙伴加入，他们才正式组建了这个乐队，取名 Moonlit Sailor。

他们刚开始定位为独立摇滚，2007年才决定去掉人声，转型为后摇，并于2008年发行了第一张专辑，2009年签约美国独立音乐唱片公司Deep Elm Records，并且后面和日本的XTAL Records和中国的声演坊都有签约。

Deep Elm 是诞生于1995年美国纽约的独立音乐唱片公司。这是一家充满情怀和理想主义的唱片公司，他们宣称“operates for glory, not gold”。他们旗下的乐队或艺人总共发行了超过225张专辑，全部专辑均可以用“自由定价”（name your price）方式获得数字版，一般支付$1以上的任何价格就可以。

详细可以从他们官网了解：https://deepelmdigital.com/

乐队里有几个成员还有自己的Side project，也就是其他不同风格的乐队。比如Adam和Oscar两人组建了一个名叫U137的后摇乐队，并于2013年发行了第一张专辑《Dreamer On The Run》。 2016年Adam又和Oscar组建了一个名叫Sons of London的摇滚乐队，总共发行了两首单曲，可以在SoundCloud上听到，非常不错！

当然他们的这两支乐队全部签约Deep Elm。

专辑

Moonlit Sailor总共发行了四张专辑，每一张专辑都不太一样，但是每一张都是精品。他们一大特色就是能让乐迷们从每次精心设计的专辑封面一窥歌曲的样貌。每首曲子时长都很精炼，既不会感觉拖沓冗长，也不会让人意犹未尽突然戛然而止。一把吉他当主音，一把吉他当伴奏，贝斯始终连贯其中，时不时的鼓声既让人惊喜又感觉恰到好处，每一首都旋律优美，明亮快乐，引人入胜，流连忘返。

作为后摇曲，没有歌词，没有人声，仅仅靠吉他、贝斯和鼓三种乐器演绎出的曲子，竟然如此触人心灵，让人充满温暖，引人积极向上。没有歌词和人声束缚，你不知道乐队通过纯粹的音乐想传达什么感情给听者，但作为听者，你不需要知道，因为你会被不由自主触发到那一份只和你有关的感情，也许心系往事，也许产生共鸣。

1. A Footprint Of Feelings

这是一张发行于2008年8月5号的处女专辑（Debut album)，当年他们才18到20岁！专辑封里有一艘小船在宁静的月光下安静的航行，和乐队名字 Moonlit Sailor 遥相呼应。我觉得这张专辑基本上确定了他们乐队以后的风格，后摇不能只是阴暗压抑，也需要明朗豁达。音乐是让人快乐的，这几个年轻的少年做到了，发完第一张专辑他们就开始了欧洲巡演，瑞典、德国、丹麦、捷克、荷兰、比利时等，而且全部由他们四个人亲力亲为安排的。

这张专辑里面我最喜欢的是《Earls Court》!

2. So Close To Life

签约Deep Elm Records之后，他们于2009年11月18号发行了第二张专辑，专辑里面的曲子完全把希望和积极向上演绎的淋漓尽致。应该也是从这张专辑开始与日本和中国的公司签约。

《Hope》和《1994》是这张专辑中我最喜欢的两首！

3. Colors In Stereo

2011年6月8号，这一天我在还参加高考，而远在另一个世界的他们发行了第三张专辑，也是我最喜欢的一张专辑，专辑封面还成为了我各大社交账号的头像。这张专辑完全是升华，就连专辑名《Colors In Stereo》和专辑封面之美简直让我头皮发麻。而且这张专辑里面的曲子基本上都是首首红心。单曲循环多少遍？只有岁月才可知。

4. We Come From Exploding Stars

时间来到2014年2月25号，他们发行了第四张专辑，目前为止也是最后一张专辑。从专辑封面就能看出来，水手们航行到了外太空，探索着宇宙浩瀚星河。专辑里面每首曲子吉他音色更强调效果器，耳目一新的同时却依然保留着原来的味道。

中国之旅

2012年，Moonlit Sailor第一次来到中国巡演。从9月29号至10月6号，成都、重庆、广州、武汉、上海、北京、天津，每天一场。今天的他们在中国这么小众，当年肯定更不出名，能有机会到现场聆听的人是多么幸运啊！

他们还为这次中国之行拍了一个Mini版的纪录片，可以在YouTube上面看到。

可能2012年的这次中国之行应该是他们唯一的一次也是最后一次吧，因为鼓手Adam于2017年逝世了！

Adam英年早逝

天妒英才，痛心疾首，鼓手Adam于2017年6月8号与世长辞，年仅27岁。维基百科上说Adam最终没有逃脱掉这个“27俱乐部”，他的离世给这个乐队和粉丝们带来多大的打击啊。那个能写出像《Hope》这样能让自己一直引以为豪的Adam，在《Weekday Escape》中能把鼓节奏演绎得如此畅快淋漓，帅炸天的Adam，既会架子鼓，也会吉他、钢琴，编写动人旋律时独具天赋的Adam竟然真的走了，他的乐队队友以他另一个乐队U137的名义发行了一张名为《Adam Forever》的专辑，纪念这位曾经的挚友！

这张专辑可以在Spotify上面听到，简直不敢多听，听多了会哭的。

27俱乐部（英语：27 Club），或称永远的27俱乐部，是一个流行文化用语，指由一群过世时全为27岁的伟大摇滚与蓝调及流行乐音乐家，或艺术家和演员所组成的“俱乐部”。

参见维基百科。

我的年度乐队

和 Moonlit Sailor 确实相见恨晚，但是短短一年，他们给我带来的东西远远超过后摇和音乐。我还清楚的记得2018年1月27号，我第一次试听架子鼓的课程，从那天开始我就毅然决定要学好架子鼓，希望以后能组建一个后摇乐队，至少从翻奏他们的曲子开始。整整一年时间我都在业余时间学架子鼓，并且还捡起了多年不顾的乐理课程，幻想以后有机会能写出像他们那样的曲子。

我能感觉到 Moonlit Sailor 的成员也是理想主义者，和满满都是情怀的Deep Elm Records签约不是为了金钱，而是因为他们如此热爱音乐！这一点让我更加坚定我的理想主义，理想主义的人其实都很傻，但我愿意当一个这样的傻子。

发布 Anyshortcut CLI 版以及 Rust 使用半年之后的感受

2018-10-21T00:00:00Z

Anyshortcut是我发布于2017年12月的Chrome/Firefox效率插件，一直坚持订阅制收费，到目前为止注册用户将近1000位，使用信用卡订阅用户接近3%吧。

大半年前接触到Rust，被这门语言深深折服，于是从官方文档开始学习Rust，入门之后写了一个Anyshortcut CLI版。

项目地址

https://github.com/anyshortcut/anyshortcut-cli

自认为这个项目很适合Rust初学者学习。

命令行的Anyshortcut可以干什么？

因为Anyshortcut的快捷键是可以同步的，对于CLI程序是通过Access token来访问后端API来同步快捷键的。Access token可以在官网用户中心找到。

用Access token登录之后即可把所有快捷键同步下来，然后可以使用命令行快速打开网页。

比如，我给https://www.google.com 绑定了快捷键G，那就可以输入as g快速用默认浏览器打开Google。

$ as g
Url: https://www.google.com/

其他的混合快捷键、二级快捷键也是类似，就不再介绍了。

当然这里的命令as是anyshortcut的别名，要不然名字太长了，根本就算不上效率工具了。

alias as=$(which anyshortcut)

怎么安装

如果你是Rust 开发者，很简单，用cargo install就行。

cargo install anyshortcut

当然我也提交了Homebrew，但是因为GitHub repository not notable enough (<30 forks, <30 watchers and <75 stars) 的原因暂时没有被merge，希望以后能达到这个要求。Merge之后就可以通过brew安装了。

brew install anyshortcut

使用Rust半年之后的感想

申明：除了Rust 之外我个人熟悉的编程语言只有C++ 2003, Java, Python, Javascript, Groovy，我并没有研究过各种编程语言，甚至Ruby、Go、Swift、Kotlin、Scala，Haskell等我都一律没有去学过，所以这些只能算比较浅显的感想。

相识恨晚。 其实我大概16年的时候才知道的Rust，当时认识几个不错的程序员在写一些Rust的项目，不过我还不以为然，以为又是一门什么赚噱头的新语言，就没有太多的关注它。直到今年初机缘巧合才真正的激发我学Rust的强烈兴趣。目前我也看到了好几位和我一样学了Rust之后发表Rust真香的赞叹！
概念很多，门槛很高。 Rust是一门对标C/C++的系统级编程语言，它在既能处理好内存安全、线程安全的这些问题的同时也支持各种现代编程语言的特性，比如函数式、错误处理、并发处理、依赖管理等。写起来还是比较优雅的。当然Rust没有自动GC，所以它引入了很多Rust独有的新概念，比如生命周期、所有权、借用等让初学者非常不适应。
优秀的依赖管理和文档生成工具。 Rust的Cargo绝对是我用过的所有语言里面最好的依赖管理工具，非常省心人性化。Cargo提供的文档生成体验也很棒，这才是现代化的编程语言应该具有的。
越写越爱不释手。 写Rust最难过的一关就是编译器，你会被它折磨的心累，太严格太死板了，稍微不对就会编译不过。当然Rust官方也在优化这一点，比如NLL。但是只要你过了编译器这一关，编译没问题，线上运行绝对没有问题(Unsafe的代码、内存泄漏或溢出除外）,不像Java编译过了，线上还有可能出现NPE啊啥的。编译成功之后非常放心，几乎不需要花时间去线上复现解决那些诡异的bug。
国内很冷门，但前景很看好。 Rust在国内确实太冷门了，目前社区也很少，Rust相关的会议更是寥寥无几，招聘Rust的职位非常少，除了蚂蚁金服、今日头条、Pingcap和区块链公司，其他公司的职位几乎没有。另外Rust也还缺少明星级的项目，这些都需要时间去沉淀吧。目前国内学Rust的基本上都是出于情怀和对这门语言的喜爱。Rust不管是在系统级编程、网络编程、并发编程、嵌入式、WebAssembly等方面都在发力，德国越来越多的公司在使用Rust应用于他们的工业4.0，甩我们多少条街？Github发布的2018年终总结提到Rust是增长速度最快的编程语言第五位。我学Rust也是出于情怀，但是我还是相信Rust在全世界的前景还是非常光明的（没有特指中国）。

Folyd 的由来

2018-04-30T00:00:00Z

Folyd是我从13年大二开始一直在使用的网名，一直到陪伴我到现在，当初为什么取这个名字，没有什么特别的原因，完全是一些机缘巧合和阴差阳错。

Floyd算法

学过CS的人应该都知道Floyd是什么，在图论中有一个很著名的求任意两点间最短路径的算法，它的时间复杂度是O(n³)，它的优点是很容易理解和实现，它就叫Floyd算法。这个算法名称是以创始人之一、1978年图灵奖获得者、斯坦福大学计算机科学系教授Robert W. Floyd命名的。

阴差阳错

大二数据结构课程第一次学到Floyd算法，觉得很有意思，然后不知道哪来的念头想以这个名字注册一个.com域名，但是当时在输入的时候阴差阳错的把floyd打成了folyd。注册成功之后才发现自己把域名打错了，其实floyd.com这个域名早在1997年就被注册了。

将错就错

2013年1月12号第一次注册了folyd.com之后我的很多网站用户名都是Folyd，比如Github、 Stackoverflow、Gitlab等等。后面因为没有续费域名被收回，断断续续几年时间里重新注册了两次，总感觉舍不得丢掉这个域名。

未来的Folyd

现在的folyd.com是我基于Python优秀的开源CMS软件Lektor编写的，整体定位是个人网站，整个网站的UI偏向于极简主义，非常简洁直观。之后会不定期在这里更新自己的博文，介绍自己的项目等等。

Folyd's Blog

我的 2022 总结

回顾

To-D 观察室

Zine

Rust Search Extension

duo

其他值得一提的事情

不变和改变

不变

改变

Rust Pin 进阶

Pin API 剖析

Pin 额外的属性

#[fundamental]

#[repr(transparent)]

Pin 实现的 trait

Unpin

Deref 和 DerefMut

Future

Unpin 和 Future

Unpin 是 safe trait

为什么 Future 可以是 Unpin 的

Pin 的 Future 实现

为什么需要 Unpin 限定

其他需要 Pin 的场景

Intrusive collections

其他

总结

优化 Rust 标准库的 binary_search

分支预测(Branch prediction)

分支

指令流水线(instruction pipelining)

为什么需要分支预测？

热循环中避免分支预测

优化（2）

整数溢出问题

为什么 slice::len() 对于 non-ZST 最大值是 isize 呢？

最终版本

总结

Rust 的 Pin 与 Unpin

概念

到底什么是move？

自引用结构体的move

根源是什么？

Pin闪亮登场

如何构造一个Pin

Pin::new()

Pin::new_unchecked()

其他

Pin的应用

Pin到栈上

Pin到堆上

Future

其他

总结

Rust 未来 Generator 语法探索之 Propane

现状

Propane

Moonlit Sailor - 我的年度乐队

Moonlit Sailor简介

专辑

中国之旅

Adam英年早逝

我的年度乐队

发布 Anyshortcut CLI 版以及 Rust 使用半年之后的感受

项目地址

命令行的Anyshortcut可以干什么？

怎么安装

使用Rust半年之后的感想

Folyd 的由来

Floyd算法

阴差阳错

将错就错

未来的Folyd

为什么 `slice::len()` 对于 non-ZST 最大值是 `isize` 呢？