Decision for p107 "Code and Name Organization" (#174)

* Decision for p107 "Code and Name Organization"

Create initial decision doc.

* Update proposals/p107_decision.md

Co-authored-by: Jon Meow <46229924+jonmeow@users.noreply.github.com>

* Update proposals/p107_decision.md

Co-authored-by: Jon Meow <46229924+jonmeow@users.noreply.github.com>

* Update proposals/p107_decision.md

Co-authored-by: Chandler Carruth <chandlerc@gmail.com>

* Update proposals/p107_decision.md

Co-authored-by: Jon Meow <46229924+jonmeow@users.noreply.github.com>

* Update proposals/p107_decision.md

Co-authored-by: Jon Meow <46229924+jonmeow@users.noreply.github.com>

Co-authored-by: Jon Meow <46229924+jonmeow@users.noreply.github.com>
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>

proposals/p107_decision.md

@@ -0,0 +1,62 @@
+# Decision for: Code and name organization
+
+<!--
+Part of the Carbon Language project, under the Apache License v2.0 with LLVM
+Exceptions. See /LICENSE for license information.
+SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+-->
+
+Proposal accepted on 2020-10-06
+
+Affirming:
+
+-   [austern](https://github.com/austern)
+-   [chandlerc](https://github.com/chandlerc)
+-   [josh11b](https://github.com/josh11b)
+-   [tituswinters](https://github.com/tituswinters)
+-   [zygoloid](https://github.com/zygoloid)
+
+Abstaining:
+
+-   [geoffromer](https://github.com/geoffromer)
+-   [gribozavr](https://github.com/gribozavr)
+-   [noncombatant](https://github.com/noncombatant)
+
+## Open questions
+
+### Should we switch to a library-oriented structure that's package-agnostic?
+
+-   **Decision:** No.
+-   **Rationale:** While this would simplify the overall set of constructs
+    needed, removing the concept of a global namespace remained desirable and
+    would require re-introducing much of the complexity around top-level
+    namespaces. Overall, the simplification trade-off didn't seem significantly
+    better.
+
+## Should there be a tight association between file paths and packages/libraries?
+
+-   **Decision:** Yes, for the API files in libraries. Specifically, the library
+    name should still be written in the source, but it should be checked to
+    match -- after some platform-specific translation -- against the path.
+-   **Note:** Sufficient restrictions to result in a portable and simple
+    translation on different filesystems should be imposed, but the Core team
+    was happy for these restrictions to be developed as part of implementation
+    work.
+-   **Rationale:** This will improve usability and readability for users by
+    making it obvious how to find the files that are being imported. Similarly,
+    this will improve tooling by increasing the ease with which tools can find
+    imported APIs.
+
+## Rationale
+
+This proposal provides an organizational structure that seems both workable and
+aligns well with Carbon's goals:
+
+-   Distinct and required top-level namespace -- "package"s from the proposal --
+    both matches software best practices for long-term evolution, and avoids
+    complex and user-confusing corner cases.
+-   Providing a fine-grained import structure as provided by the "library"
+    concept supports scalable build system implementations while ensuring
+    explicit dependencies.
+-   The structured namespace facilities provide a clear mechanism to migrate
+    existing hierarchical naming structures in C++ code.