Jeff Burdges

> What if, during the waiting period, Babe misses a slot or two and block times elongate? Will we discard a viable candidate, then? And do we care? We hopefully...

We'll collect some design notes in https://hackmd.io/@rgbPIkIdTwSICPuAq67Jbw/rkipBanIn

Very nice RFC. It's unlikely the root binary crate should provide these or micro-manage them too much. It's most likely library crate features control these, which enables many options. If...

As written, linkers can do this resolution, no? Isn't that enough reason this should still exist, even if some non-linker-friendly trait based scheme emerges in 5 years or whatever?

Yes, I'd worry that `#[derive(Deref)]` encourages [deref polymorphism](https://github.com/rust-unofficial/patterns/blob/master/anti_patterns/deref.md), which bring subtle problems. At least the variance issues should not be problematic here, right? I suppose `Deref`/`DerefMut` have some history with...

We should clarify the problematic scenario here: We've a crate `victim` that imports say `rand::Rng` and `attack_vactor::prelude::*` for some other crate `attack_vactor`, so now adding a subtrait of `Rand` to...

I think "complexity" does not capture the concerns here, really neither does "intuitiveness". We do not need a single word that captures the concerns though. Wow @programmerjake that's really nasty....

I'll single out the simplest seeming solution: Add a `#[subshadow]` attribute which causes a supertrait item to shadow a subtrait iterm, but otherwise the name conflict causes an error like...

> Nothing about this RFC is specific to the standard library, Also in my proposal. > so I don't see how you envision an edition fitting into this An edition...

> we actually want to prefer the subtrait method because it may have a different signature than the one in the supertrait At least technically, those concerns wind up fairly...