Clarify collection types with non-allocating constructors, note that destructors will never run, acknowledge .dtors as alternative

Author: thepowersgang

text/0000-drop-types-in-const.md

@@ -11,8 +11,8 @@ Allow types with destructors to be used in `static` items and in `const` functio
 # Motivation
 [motivation]: #motivation
 
-Most collection types do not allocate any memory when constructed empty. With the change to make leaking safe, the restriction on `static` items with destructors
-is no longer required to be a hard error.
+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
 runtime-initialisation for global variables.
@@ -21,6 +21,7 @@ runtime-initialisation for global variables.
 [design]: #detailed-design
 
 - Lift the restriction on types with destructors being used in statics.
+ - `static`s containing Drop-types will not run the destructor upon program/thread exit.
  - (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.
@@ -59,8 +60,9 @@ Destructors do not run on `static` items (by design), so this can lead to unexpe
 
 - Runtime initialisation of a raw pointer can be used instead (as the `lazy_static` crate currently does on stable)
 - On nightly, a bug related to `static` and `UnsafeCell<Option<T>>` can be used to remove the dynamic allocation.
-
-Both of these alternatives require runtime initialisation, and incur a checking overhead on subsequent accesses.
+ - Both of these alternatives require runtime initialisation, and incur a checking overhead on subsequent accesses.
+- Leaking of objects could be addressed by using C++-style `.dtors` support
+ - This is undesirable, as it introduces confusion around destructor execution order.
 
 # Unresolved questions
 [unresolved]: #unresolved-questions