Stream: general

Topic: dropck_eyepatch


pnkfelix (Nov 27 2018 at 14:45, on Zulip):

right-o

centril (Nov 27 2018 at 14:46, on Zulip):

do we still have the dropck_eyepatch and #[unsafe_destructor_blind_to_params]?

pnkfelix (Nov 27 2018 at 14:47, on Zulip):

We should remove #[unsafe_destructor_blind_to_params] if we haven't already

centril (Nov 27 2018 at 14:47, on Zulip):

<https://github.com/rust-lang/rust/issues/34761>

pnkfelix (Nov 27 2018 at 14:47, on Zulip):

I believe dropck_eyepatch is the feature gate for #[may_dangle], which we need to keep until we have a more general better solution to the problem it is solving.

centril (Nov 27 2018 at 14:48, on Zulip):

@pnkfelix what was the problem again?

pnkfelix (Nov 27 2018 at 14:48, on Zulip):

The destructor for Vec<T>

pnkfelix (Nov 27 2018 at 14:49, on Zulip):

is guaranteed to run without running any code for instances of T (apart from their own destructors)

pnkfelix (Nov 27 2018 at 14:49, on Zulip):

which means its sound to e.g. have a Vec where the elements hold references to other elements of the Vec

pnkfelix (Nov 27 2018 at 14:49, on Zulip):

If a user tries to implement Vec themselves

pnkfelix (Nov 27 2018 at 14:49, on Zulip):

and does not opt into the dropck_eyepatch

pnkfelix (Nov 27 2018 at 14:50, on Zulip):

they (may) discover that their version of a vec is not as expressive as Vec in the stdlib

pnkfelix (Nov 27 2018 at 14:50, on Zulip):

since their version cannot store cyclic structures

pnkfelix (Nov 27 2018 at 14:50, on Zulip):

There's an issue about this, hold on

pnkfelix (Nov 27 2018 at 14:51, on Zulip):

(and let me rename this divergent topic)

pnkfelix (Nov 27 2018 at 14:53, on Zulip):

@Mazdak Farrokhzad okay you can read more here: <https://github.com/rust-lang/rfcs/blob/master/text/1238-nonparametric-dropck.md#why-we-need-an-escape-hatch>

centril (Nov 27 2018 at 14:53, on Zulip):

cheers

pnkfelix (Nov 27 2018 at 14:55, on Zulip):

and of course far far more gory (and outdated) detail is available in <https://github.com/rust-lang/rfcs/blob/master/text/0769-sound-generic-drop.md>

RalfJ (Nov 27 2018 at 14:56, on Zulip):

(which wasn't sound)

pnkfelix (Nov 27 2018 at 14:56, on Zulip):

yeah that's why I added "outdated" but I should have put something stronger.

pnkfelix (Nov 27 2018 at 14:57, on Zulip):

why it was unsound is discussed briefly (with links to more detail) here: <https://github.com/rust-lang/rfcs/blob/master/text/1238-nonparametric-dropck.md#mistakes-were-made>

centril (Nov 27 2018 at 14:58, on Zulip):

@pnkfelix there, fixed the title: <https://github.com/rust-lang/rfcs/pull/769> ;)

pnkfelix (Nov 27 2018 at 15:00, on Zulip):

"mistakes were made" is one of my favorite uses of the passive voice to avoid pointing a finger at myself

centril (Nov 27 2018 at 15:01, on Zulip):

there's a shorthand for that: "oops" =P

centril (Nov 27 2018 at 15:59, on Zulip):

@pnkfelix After reading 1238 I got nothing; #[may_dangle] is quite an ad-hoc thing to say ;)

centril (Nov 27 2018 at 15:59, on Zulip):

nothing comes to mind wrt. generalizations

centril (Nov 27 2018 at 15:59, on Zulip):

(except that as person who likes Haskell & co. I like parametricity ^.^)

centril (Nov 27 2018 at 16:00, on Zulip):

(and I sure hope we get specialization and that it becomes good for all the trouble it has caused so far and keeps causing...)

RalfJ (Nov 28 2018 at 07:06, on Zulip):

@pnkfelix After reading 1238 I got nothing; #[may_dangle] is quite an ad-hoc thing to say ;)

it's actually not

RalfJ (Nov 28 2018 at 07:07, on Zulip):

but I haven't seen a good description of it anywhere either had to puzzle together my own

RalfJ (Nov 28 2018 at 07:07, on Zulip):

(and talking to @Ariel Ben-Yehuda helped)

RalfJ (Nov 28 2018 at 07:07, on Zulip):

I guess I should write a blog post...

RalfJ (Nov 28 2018 at 07:07, on Zulip):

but probably not before next week

pnkfelix (Nov 28 2018 at 08:45, on Zulip):

Wait, 1238 isn’t going to explain may_dangle

pnkfelix (Nov 28 2018 at 08:48, on Zulip):

For that, you would start with https://github.com/rust-lang/rfcs/blob/master/text/1327-dropck-param-eyepatch.md (and then muddle along seeking a better explanation the way Ralf describes)

pnkfelix (Nov 28 2018 at 08:51, on Zulip):

The heart of it is this line from that RFC: “When used on a lifetime, e.g. #[may_dangle] 'a, the programmer is asserting that no data behind a reference of lifetime 'a will be accessed by the destructor.”

pnkfelix (Nov 28 2018 at 08:57, on Zulip):

The application to type parameters is specified as having an arguably stronger constraint (roughly “you can only move or drop instances of a #[may_dangle] T”) ... but it might make more sense to describe that constraint as a conservative approximation to the actual goal constraint. A more precise constraint might be described as applying #[may_dangle] to every lifetime that arises in the instantiation of T... but I’m not sure that is a sensible description. And in any case the conservative approximation conveys the kind of code we expect to occur in practice for such uses

centril (Nov 28 2018 at 09:45, on Zulip):

@pnkfelix ah so for tyvars its sort of the transitive closure of the idea on lifetimes

centril (Nov 28 2018 at 09:46, on Zulip):

it's still ad-hoc ;)

RalfJ (Nov 28 2018 at 09:52, on Zulip):

I think I have an explanation you'll like much more @centril ^^ hopefully I can write it down next week...

Last update: Nov 20 2019 at 12:45UTC