QuineDot

> * Fundamental types, adding blanket trait impls, and the re-rebalancing RFC. There is a section on fundamental types that has changed as part of RFC 1023 and RFC 2451...

[January 2020, negative `impl` for non-auto-traits feature lands in order to close a soundness hole.](https://github.com/rust-lang/rust/issues/68318) To be RFC'd or discarded eventually; implications to the language TBD.

> Comparing that issue to https://doc.rust-lang.org/nightly/reference/destructors.html, it seems like the current docs are fairly clear which values have explicit drop code generated. The interaction between NLL, `Drop` implementers, and scope...

CC @petrochenkov, who [has expressed concern over complicating method resolution further without an overarching vision.](https://github.com/rust-lang/rust/issues/89151#issuecomment-959067391)

I wanted to note a scenario in Rust today where a programmer must write a refined implementation _without the expectation it can be called_, or perhaps even _the expectation it...

> Based on my reading of [RFC 401](https://rust-lang.github.io/rfcs/0401-coercions.html) and [the reference,](https://doc.rust-lang.org/reference/type-coercions.html) all three should compile @steffahn pointed out that this can't actually happen (without impractical levels of magic); I'll try...

To reiterate the key part of #1321 over here, it is currently worded that > Then, for each candidate type `T`, search [...] > * `T`'s inherent methods [...] >...

I don't think it's about lifetimes per se, it's more of a general lint. "If you're doing something on the level of pointers, you have to opt in to being...

> Okay, I had not thought of it from that perspective. But let me first understand if we understand the same by _daemon thread_? Ah, okay -- that isn't the...

The layout of wide pointers (or references) isn't guaranteed generally, nor guaranteed to be the same between different types. That is, they're not guaranteed to be consistent. (The order of...