Expand detailed design

Author: thepowersgang

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

@@ -6,7 +6,7 @@
 # Summary
 [summary]: #summary
 
-Allow types with destructors to be used in `const`/`static` items, as long as the destructor is never run during `const` evaluation.
+Allow types with destructors to be used in `static` items and in `cosnt` functions, as long as the destructor never needs to run in const context.
 
 # Motivation
 [motivation]: #motivation
@@ -20,17 +20,17 @@ runtime-initialisation for global variables.
 # Detailed design
 [design]: #detailed-design
 
-
-- allow destructors in statics
- - optionally warn about the "potential leak"
-- allow instantiating structures that impl Drop in constant expressions
-- prevent const items from holding values with destructors, but allow const fn to return them
-- disallow constant expressions which would result in the Drop impl getting called, where they not in a constant context
+- Lift the restriction on types with destructors being used in statics.
+ - (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 wth destructors.
+- Disallow constant expressions which would result in the destructor being called (if the code were run at runtime).
 
 # Drawbacks
 [drawbacks]: #drawbacks
 
-Destructors do not run on `static` items (by design), so this can lead to unexpected behavior when a side-effecting type is stored in a `static` (e.g. a RAII temporary folder handle). However, this can already happen using the `lazy_static` crate.
+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.
 
 # Alternatives
 [alternatives]: #alternatives