pre-commit

proposals/p3980.md

@@ -606,12 +606,24 @@ discussed other syntaxes for `extern` + `extern library`. These were mainly
 `has_extern`/`is_extern`/`externed` + `extern`. The current syntax is more
 verbose, but was chosen because:
 
--   Providing behavior of imports being incomplete orthogonally but using the same keyword allowed us have a single meaning for the `export` keyword and consistent usage of it on declarations.
-    -   Enabling this behavior independently wasn't seen as a problem by the leads and potentially useful even if not the primary motivation. The primary motivation was orthogonality of features.
-    -   Within this context `extern` seemed like an acceptable name, and alternative names seemed significantly less good. It also gives us only one new keyword.
--   Adding the owning library with `extern library "<owning_library"` will hopefully give us better diagnostics, better human readability and understandability of the code.
-    -   It is _very_ verbose, but this verbosity goes on the forward declaration in the non-owning library, which we expect to be read less often.
-    -   And if in practice we find the verbosity becomes a significant issue we can revisit syntaxes to address that specifically. For example, if we have significant repetiton, we might consider a grouping structure such as `extern library "..." { <many forward declarations> }`.
+-   Providing behavior of imports being incomplete orthogonally but using the
+    same keyword allowed us have a single meaning for the `export` keyword and
+    consistent usage of it on declarations.
+    -   Enabling this behavior independently wasn't seen as a problem by the
+        leads and potentially useful even if not the primary motivation. The
+        primary motivation was orthogonality of features.
+    -   Within this context `extern` seemed like an acceptable name, and
+        alternative names seemed significantly less good. It also gives us only
+        one new keyword.
+-   Adding the owning library with `extern library "<owning_library>"` will
+    hopefully give us better diagnostics, better human readability and
+    understandability of the code.
+    -   It is _very_ verbose, but this verbosity goes on the forward declaration
+        in the non-owning library, which we expect to be read less often.
+    -   And if in practice we find the verbosity becomes a significant issue we
+        can revisit syntaxes to address that specifically. For example, if we
+        have significant repetiton, we might consider a grouping structure such
+        as `extern library "..." { <many forward declarations> }`.
 
 ### Have types with `extern` members re-export them