[64] SE-0162 under review

_drafts/2017-04-06-issue-64.md

@@ -49,6 +49,14 @@ Speaking of JP Simard, he released [SourceKitten 0.17.1](https://github.com/jpsi
 
 ### Proposals in review
 
+[SE-0155](https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md): *Normalize Enum Case Representation* by Daniel Duan and Joe Groff is [under review](https://lists.swift.org/pipermail/swift-evolution-announce/2017-March/000336.html).
+
+> In Swift 3, associated values of an enum case are represented by a tuple. This implementation causes inconsistencies in case declaration, construction and pattern matching in several places.
+>
+> Enums, therefore, can be made more "regular" when we replace tuple as the representation of associated case values. This proposal aims to define the effect of doings so on various parts of the language.
+>
+> Swift-evolution thread: [Normalize Enum Case Representation (rev. 2)](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170306/033626.html)
+
 [SE-0161](https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md): *Smart KeyPaths: Better Key-Value Coding for Swift* by David Smith, Michael LeHew, and Joe Groff is [under review](https://lists.swift.org/pipermail/swift-evolution-announce/2017-March/000334.html).
 
 > We propose a family of concrete _Key Path_ types that represent uninvoked references to properties that can be composed to form paths through many values and directly get/set their underlying values.
@@ -67,13 +75,13 @@ Speaking of JP Simard, he released [SourceKitten 0.17.1](https://github.com/jpsi
 > **More Expressive KeyPaths**<br/>
 > We would also like to support being able to use _Key Paths_ to access into collections, which is not currently possible.
 
-[SE-0155](https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md): *Normalize Enum Case Representation* by Daniel Duan and Joe Groff is [under review](https://lists.swift.org/pipermail/swift-evolution-announce/2017-March/000336.html).
+[SE-0162](https://github.com/apple/swift-evolution/blob/master/proposals/0162-package-manager-custom-target-layouts.md): *Package Manager Custom Target Layouts* by Ankit Aggarwal is [under review](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170403/034997.html).
 
-> In Swift 3, associated values of an enum case are represented by a tuple. This implementation causes inconsistencies in case declaration, construction and pattern matching in several places.
+> This proposal enhances the `Package.swift` manifest APIs to support custom target layouts, and removes a convention which allowed omission of targets from the manifest.
 >
-> Enums, therefore, can be made more "regular" when we replace tuple as the representation of associated case values. This proposal aims to define the effect of doings so on various parts of the language.
+> The Package Manager uses a convention system to infer targets structure from disk layout. This works well for most packages, which can easily adopt the conventions, and frees users from needing to update their `Package.swift` file every time they add or remove sources. Adopting the conventions is more difficult for some packages, however – especially existing C libraries or large projects, which would be difficult to reorganize. We intend to give users a way to make such projects into packages without needing to conform to our conventions.
 >
-> Swift-evolution thread: [Normalize Enum Case Representation (rev. 2)](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170306/033626.html)
+> The current convention rules make it very convenient to add new targets and source files by inferring them automatically from disk, but they also can be confusing, overly-implicit, and difficult to debug; for example, if the user does not follow the conventions correctly which determine their targets, they may wind up with targets they don't expect, or not having targets they did expect, and either way their clients can't easily see which targets are available by looking at the `Package.swift` manifest. We want to retain convenience where it really matters, such as easy addition of new source files, but require explicit declarations where being explicit adds significant value. We also want to make sure that the implicit conventions we keep are straightforward and easy to remember.
 
 ### Mailing lists