Stream: t-lang

Topic: negative impls

nikomatsakis (Jan 07 2020 at 22:47, on Zulip):

Hey @T-lang I'd appreciate feedback on this internals thread, specifically on this question I raised there:

I guess I don't want this thread to necessarily go too far down the design specifics -- at least not yet -- but I'd like to answer the question of "how much of this design we feel we need to do and when".

My inclination, I think, is that we should immediately prototype a way to bar the "evil" DerefMut impl with minimal implications for stable code. Then we can assess how far down the rest of the design path to go -- we don't necessarily have to do it now, though it'd be good to start sketching out what a coherent overall design looks like around traits. (I'd like to be doing that in the wg-traits repository, probably, though till now the focus there has been on implementation questions primarily.)
liked this

centril (Jan 07 2020 at 22:48, on Zulip):

Haven't read the internals thread yet -- from the meeting I didn't know if I favored the negative impl or unsafe trait approach, so I'll need to do more reading before I can answer

centril (Jan 07 2020 at 22:49, on Zulip):

prototyping seems sensible though

nikomatsakis (Jan 07 2020 at 22:50, on Zulip):

@RalfJ had a good post summarizing a lot of what they said in the meeting

nikomatsakis (Jan 07 2020 at 22:51, on Zulip):

which also I think does a decent job of sketching what you wanted -- which is, what is the "proof obligation" of someone who invokes new_unchecked

centril (Jan 07 2020 at 22:51, on Zulip):

cool :slight_smile:

nikomatsakis (Jan 07 2020 at 22:51, on Zulip):

anyway, I'll take a look at prototyping

RalfJ (Jan 08 2020 at 09:04, on Zulip):

yes, that post was also specifically a response to @centril's request for a writeup during the meeting ;)

nikomatsakis (Jan 08 2020 at 14:17, on Zulip):

PR with preliminary support for negative impls is posted.

gnzlbg (Jan 09 2020 at 11:39, on Zulip):
trait Integer {}
trait Float {}

struct I32(i32);
struct F32(f32);

impl Integer for I32 {}
impl Float for F32 {}

trait Foo {}
impl<T: Integer> Foo for T {}
impl<T: Float> Foo for T {}

// Can I fix the overlapping error with negative impls?
// impl<T: Integer> !Float for T {}
// impl>T: Float> !Integer for T {}
gnzlbg (Jan 09 2020 at 11:40, on Zulip):

Notice that right now, since there can be a T: Integer + Float, the two blanket impls for T: Integer and T: Float overlap.

gnzlbg (Jan 09 2020 at 11:41, on Zulip):

However, if I was able to express that if a T: Integer is always !Float and that a T: Float is always !Integer, then these two blanket impls do not overlap.

gnzlbg (Jan 09 2020 at 11:43, on Zulip):

Can I express that with the negative impls feature?

nikomatsakis (Jan 09 2020 at 20:00, on Zulip):


nikomatsakis (Jan 09 2020 at 20:00, on Zulip):

Not as implemented, anyway.

gnzlbg (Jan 10 2020 at 08:47, on Zulip):

Thanks, that clarifies the scope of the feature for me

scottmcm (Apr 17 2020 at 21:01, on Zulip):

Another observation in support of this: right now the lint isn't all that useful, because it's fairly often on purpose. Being able to have impl !Copy for Foo to explicitly decide against ever offering copy would be a nice improvement.

Last update: May 27 2020 at 23:15UTC