Amend #1440: allow const items to contain drop types.

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
 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.
 
+Destructors _will_ run on `const` items at runtime, which can lead to unexpected behavior when a type's destructor has effects outside the program.
+
 # Alternatives
 [alternatives]: #alternatives