Merge pull request #1817 from SergioBenitez/master

Amend #1440: allow `const` items to contain drop types.
rust-lang · Jul 25, 2017 · 135c83c · 135c83c
2 parents 4a27a85 5a9a2b2
commit 135c83c
Showing 1 changed file with 11 additions and 7 deletions.
diff --git a/text/1440-drop-types-in-const.md b/text/1440-drop-types-in-const.md
@@ -6,27  6,27 @@
 # Summary
 [summary]: #summary
 
-Allow types with destructors to be used in `static` items and in `const` functions, as long as the destructor never needs to run in const context.
 Allow types with destructors to be used in `static` items, `const` items, and `const` functions.
 
 # Motivation
 [motivation]: #motivation
 
-Some of the collection types do not allocate any memory when constructed empty (most notably `Vec`). With the change to make leaking safe, the restriction on `static` items with destructors
 Some of the collection types do not allocate any memory when constructed empty (most notably `Vec`). With the change to make leaking safe, the restriction on `static` or `const` items with destructors
 is no longer required to be a hard error (as it is safe and accepted that these destructors may never run).
 
-Allowing types with destructors to be directly used in `const` functions and stored in `static`s will remove the need to have
 Allowing types with destructors to be directly used in `const` functions and stored in `static`s or `const`s will remove the need to have
 runtime-initialisation for global variables.
 
 # Detailed design
 [design]: #detailed-design
 
-- Lift the restriction on types with destructors being used in statics.
 - Lift the restriction on types with destructors being used in `static` or `const` items.
  - `static`s containing Drop-types will not run the destructor upon program/thread exit.
  - `const`s containing Drop-types _will_ run the destructor at the appropriate point in the program.
  - (Optionally adding a lint that warn about the possibility of resource leak)
 - Alloc instantiating structures with destructors in constant expressions,
-- Continue to prevent `const` items from holding types with destructors.
 - Allow `const fn` to return types with destructors.
-- Disallow constant expressions which would result in the destructor being called (if the code were run at runtime).
 - Disallow constant expressions that require destructors to run during compile-time constant evaluation (i.e: a `drop(foo)` in a `const fn`).
 
 ## Examples
 Assuming that `RwLock` and `Vec` have `const fn new` methods, the following example is possible and avoids runtime validity checks.
@@ -38,12  38,14 @@ trait LogHandler: Send   Sync {
 }
 /// List of registered logging handlers
 static S_LOGGERS: RwLock<Vec< Box<LogHandler> >> = RwLock::new( Vec::new() );
 
 /// Just an empty byte vector.
 const EMPTY_BYTE_VEC: Vec<u8> = Vec::new();
 ```
 
 Disallowed code
 ```rust
 static VAL: usize = (Vec::<u8>::new(), 0).1;	// The `Vec` would be dropped
-const EMPTY_BYTE_VEC: Vec<u8> = Vec::new();	// `const` items can't have destructors
 
 const fn sample(_v: Vec<u8>) -> usize {
 	0	// Discards the input vector, dropping it
@@ -55,6  57,8 @@ const fn sample(_v: Vec<u8>) -> usize {
 
 Destructors do not run on `static` items (by design), so this can lead to unexpected behavior when a type's destructor has effects outside the program (e.g. a RAII temporary folder handle, which deletes the folder on drop). However, this can already happen using the `lazy_static` crate.
 
 A `const` item's destructor _will_ run at each point where the `const` item is used. If a `const` item is never used, its destructor will never run. These behaviors may be unexpected.
 
 # Alternatives
 [alternatives]: #alternatives