Amend #1268 with a more feasible proposal post-specialization

[sgrif]

I took a swing at implementing the original RFC, and it became clear that it made much more sense when described as a modifier to specialization, rather that treating marker traits differently. After writing a proof of concept implementation, I believe this is the easier path forward.

Rendered

[aturon]

Can you repoint this at the numbered RFC, rather than the 0000 file as it is currently?

(Sorry this has been sitting in the queue for so long...)

[arielb1]

@sgrif

But the impls do not specialize one another. When we get lattice specialization, we could just not require intersection impls.

[sgrif]

@aturon Sorry not quite sure what you're asking, you want me to rename the file? Or you want me to edit the original RFC to include these changes?

[aturon]

@sgrif OK, so looking at this again, I have to agree with @arielb1 that I'm a bit worried about taking this route. In particular, at various points in the implementation we make assumptions about the specialization graph, and this would introduce cycles in that graph which could cause trouble.

I think that fundamentally we're going to need some special-casing here. FWIW, I don't think the original RFC particularly needs updating, since allowing overlap is still essentially what we want (and the rest is implementation detail).

I'd be happy to work with you and @nikomatsakis on an implementation plan and help mentor the actual work; we could set up a call if you're game.

Meantime, I suggest we close this RFC.

[sgrif]

Yeah I'd be happy to work on that. Feel free to shoot me an email to set up.