Nonparametric dropck (tracking issue for RFC 1238)
Tracking issue for rust-lang/rfcs#1238.
- [x] subtask:
#[may_dangle]attribute #34761 - [ ] can't close this until support for we have stable support for 3rd party collection types
cc @pnkfelix
Tracking issue for rust-lang/rfcs#1238.
- [x] subtask:
#[may_dangle]attribute #34761 - [ ] can't close this until we have stable support for 3rd party collection types
cc @pnkfelix
Felix S Klock II at 2019-12-30 16:18:33
- [x] subtask:
triage: P-high
Niko Matsakis at 2015-09-18 19:06:37
triage: P-medium
Niko Matsakis at 2015-10-29 11:53:21
I think this was since implemented, so closing (but please reopen if there's something left!)
Alex Crichton at 2016-02-18 18:56:14
I think this should be reopened with the
B-unstablelabel. The RFC is implemented, but the#[unsafe_destructor_blind_to_params]attribute is still behind thedropck_parametricityfeature gate which points to this as its tracking issue.#[unsafe_destructor_blind_to_params]is used forVecand a number of other types defined in the standard library. It isn’t any less useful for types outside the standard library. I’ve needed it for an arena allocator.Simon Sapin at 2016-05-04 14:13:23
I agree.
Niko Matsakis at 2016-05-04 14:21:54
Triage: feature gate still active, not aware of any work in this area.
Steve Klabnik at 2019-03-12 17:38:50
(i doubt I'm going to be attacking this problem at any point in the foreseeable future. Unassigning self.)
Felix S Klock II at 2019-05-17 10:22:46
#62568 has removed the feature gate since, but this issue says:
can't close this until we have stable support for 3rd party collection types
est31 at 2020-09-18 09:29:51
From today's @rust-lang/lang meeting: The feature seems to be working, but it may need further refinement in order to expose it as stable.
Josh Triplett at 2021-11-10 18:50:31