Josh Triplett

We reviewed this in today's @rust-lang/rust meeting. We're in favor of adding non-poisoning versions of all our mutex types. We'd like to see these all added under `std::sync::nonpoison::*`. We'd also...

We discussed this in today's @rust-lang/libs-api meeting. We agree that we should have these. We'd also like to have the matching non-`unchecked` versions (even though those are redundant with `try_into()`);...

cc @epage ; would this work for clap, as a basis for parsing user types without going through strings?

We discussed this in today's @rust-lang/libs-api meeting. We think it's important to distinguish between two possible interpretations of this: 1. As purely an optimization, where the string is expected to...

Speaking for myself here (not the team consensus): I think case 2 is something that there's pent-up demand for in the ecosystem, and it seems unlikely that we'd be able...

There are currently many issues being discussed about environment handling and concurrency. If we add this, we need to make sure it's unsafe to access.

We need to check if these are in fact different types in Windows headers, or if they're the same type and we have an error in the crate's types.

Verifying: does this mean u128/i128 are now compatible with LLVM/clang *and* GCC on Linux targets, and with MSVC on Windows -windows-msvc targets, and with MinGW on Windows -windows-gnu targets? A...

We discussed this in today's @rust-lang/lang design meeting. We came to a consensus among those present (@pnkfelix, @tmandry, @nikomatsakis, and myself) that it *is* OK to enable this conditional on...

What's the current status of this? Has there been progress on the idea of permitting this conditional on Rust being built with a sufficiently new LLVM?