dnrops
/
rfcs
mirror of https://github.com/rust-lang/rfcs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

`initialisation` -> `initialization`

This commit is contained in:
woppopo 2021-10-16 19:47:48 +09:00 committed by GitHub
parent 0dbf16e544
commit 65211297fd
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
text/1440-drop-types-in-const.md
View File

@ -15,7 +15,7 @@ Some of the collection types do not allocate any memory when constructed empty (
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 or `const`s will remove the need to have
runtime-initialisation for global variables.
runtime-initialization for global variables.
# Detailed design
[design]: #detailed-design
@ -62,9 +62,9 @@ A `const` item's destructor _will_ run at each point where the `const` item is u
# Alternatives
[alternatives]: #alternatives
- Runtime initialisation of a raw pointer can be used instead (as the `lazy_static` crate currently does on stable)
- Runtime initialization 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 initialization, 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.