Stream: t-compiler/wg-nll

Topic: how to explain PhantomData mixing w/ dropck post NLL? #70841


pnkfelix (Apr 09 2020 at 18:46, on Zulip):

@nikomatsakis @Matthew Jasper @eddyb I reclassified #70841 as a documentation issue

pnkfelix (Apr 09 2020 at 18:46, on Zulip):

but I will admit I'm at a bit of a loss about how best to describe the semantics

pnkfelix (Apr 09 2020 at 18:47, on Zulip):

"PhantomData<T> acts like it holds a T, if it is embedded in a type that has drop glue?"

pnkfelix (Apr 09 2020 at 18:47, on Zulip):

I suspect the intent is for it to behave that way when it is in a type with a destructor

eddyb (Apr 09 2020 at 18:47, on Zulip):

I would avoid "drop glue" in docs but that's just me

pnkfelix (Apr 09 2020 at 18:47, on Zulip):

but right now, a neighboring field that holds the destructor will cause dropck to flag the PhantomData too

pnkfelix (Apr 09 2020 at 18:48, on Zulip):

so I don't know the best way to describe that. Maybe just "if its embedded in a type that needs_drop " ?

Matthew Jasper (Apr 09 2020 at 19:14, on Zulip):

PhantomData<T> affecting dropck is primarily for types with a #[may_dangle] T Drop impl.

pnkfelix (Apr 09 2020 at 19:15, on Zulip):

that's true, I had mentioned that somewhere (stackoverflow? a running issue?)

nikomatsakis (Apr 10 2020 at 13:52, on Zulip):

@pnkfelix I'm surprised that a neighboring field has an effect

nikomatsakis (Apr 10 2020 at 13:56, on Zulip):

But I think I would explain it like this:

nikomatsakis (Apr 10 2020 at 13:56, on Zulip):

But it sounds like that's not quite correct

nikomatsakis (Apr 10 2020 at 13:56, on Zulip):

I wonder if we should consider this a bug :)

nikomatsakis (Apr 10 2020 at 13:57, on Zulip):

It's kind of a corner case I guess

pnkfelix (Apr 13 2020 at 18:00, on Zulip):

One thing I have been thinking about

pnkfelix (Apr 13 2020 at 18:00, on Zulip):

it might actually make sense that the neighboring field has an effect

pnkfelix (Apr 13 2020 at 18:00, on Zulip):

(even if it is unclear whether anyone actually planned for this.)

pnkfelix (Apr 13 2020 at 18:01, on Zulip):

Specifically: There can be read/write effects to a state behind that neighboring field

pnkfelix (Apr 13 2020 at 18:02, on Zulip):

and if the struct designer added the PhantomData due to such read/write effects from the neighboring field's destructor

pnkfelix (Apr 13 2020 at 18:02, on Zulip):

(that are not otherwise modeled by dropck, due to use of ... I don't know, *mut/*const) ?

pnkfelix (Apr 13 2020 at 18:03, on Zulip):

then this choice seems like it would make sense.

pnkfelix (Apr 13 2020 at 18:04, on Zulip):

(I continue to think it would be simpler to document if we were more restrictive here. But given that it would inject breakage without actually adding value, it seems pretty hard to justify...)

Jake Goulding (Apr 14 2020 at 13:56, on Zulip):

pnkfelix said:

that's true, I had mentioned that somewhere (stackoverflow? a running issue?)

yes: Why is it useful to use PhantomData to inform the compiler that a struct owns a generic if I already implement Drop?

nikomatsakis (Apr 18 2020 at 11:28, on Zulip):

@pnkfelix well, we don't know how much breakage, right?

nikomatsakis (Apr 18 2020 at 11:28, on Zulip):

I think there's a case to be made that it's a bug fix, it's definitely a grey line

nikomatsakis (Apr 18 2020 at 11:28, on Zulip):

Might be worth testing

nikomatsakis (Apr 18 2020 at 11:28, on Zulip):

I found your argument persuasive

Last update: Jun 05 2020 at 23:20UTC