Dan Gohman

To be sure, I'm still exploring the space here. One option would be to say that it's nondeterministic whether NaNs are canonicalized at boundaries. That would let implementations skip the...

Should it be possible to declare an interface with an `f64` argument where the NaN bits are a significant part of the interface contract? Choices so far include: - Yes,...

> I gave real existing libraries that real existing languages currently link to in a cross-language shared-nothing manner, and the specifications of those APIs explicitly state requirements (in line with...

More generally, on a platform where `add`, `sub`, `mul` and `sqrt` don't propagate NaN payloads, how important is it for `acos` to propagate NaN payloads?

Ah, thanks for pointing that out. So all those other traits are already stable, which means we're probably good without any further changes.

The last remaining item here is #273. That's currently waiting for https://github.com/async-rs/async-std/pull/1036 in order to support cap-async-std. Another option would be to do a 1.0 release for all the crates...

Sure. I've now published a 1.0.0-rc1 of cap-std et al. Except for cap-async-std, as that's waiting for https://github.com/async-rs/async-std/pull/1036.

I've also now released a v0.26.0-patch1, which is 0.25 plus #271 and a few other fixes, without the io-lifetimes updates, so it includes a cap-async-std release.

Indeed, `cap-std` follows Rust's `std` in this respect. For example, [`std::fs::File::set_len`](https://doc.rust-lang.org/std/fs/struct.File.html#method.set_len) takes a `&File` and not a `&mut File` even though it mutates the file. And yeah, as you say,...

It doesn't break unix. The problem in that issue is that there's a mix of both 0.25.5 and 0.25.2.