Last active
May 15, 2016 10:02
-
-
Save tinoheth/a439d67ca9f823f0cba6d7e629e3b861 to your computer and use it in GitHub Desktop.
Swift Proposal-draft
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
# Newlines as item separators in lists | |
* Proposal: [SE-NNNN](https://github.com/apple/swift-evolution/blob/master/proposals/NNNN-name.md) | |
* Author(s): [Swift Developer](https://github.com/swiftdev) | |
* Status: **[Awaiting review](#rationale)** | |
* Review manager: TBD | |
## Introduction | |
The possibility to skip semicolons to end a statement when followed by a newline is only a tiny convinience, yet it is one of the most favored differences to C. | |
While lists of statements don't need a separator character, other lists still rely on commas for this: | |
- parameters | |
- array literals | |
Swift-evolution thread: [link to the discussion thread for that proposal](https://lists.swift.org/pipermail/swift-evolution) | |
## Motivation | |
Describe the problems that this proposal seeks to address. If the | |
problem is that some common pattern is currently hard to express, show | |
how one can currently get a similar effect and describe its | |
drawbacks. If it's completely new functionality that cannot be | |
emulated, motivate why this new functionality would help Swift | |
developers create better Swift code. | |
## Proposed solution | |
Describe your solution to the problem. Provide examples and describe | |
how they work. Show how your solution is better than current | |
workarounds: is it cleaner, safer, or more efficient? | |
## Detailed design | |
Describe the design of the solution in detail. If it involves new | |
syntax in the language, show the additions and changes to the Swift | |
grammar. If it's a new API, show the full API and its documentation | |
comments detailing what it does. The detail in this section should be | |
sufficient for someone who is *not* one of the authors to be able to | |
reasonably implement the feature. | |
## Impact on existing code | |
Describe the impact that this change will have on existing code. Will some | |
Swift applications stop compiling due to this change? Will applications still | |
compile but produce different behavior than they used to? Is it | |
possible to migrate existing Swift code to use a new feature or API | |
automatically? | |
## Alternatives considered | |
Describe alternative approaches to addressing the same problem, and | |
why you chose this approach instead. | |
------------------------------------------------------------------------------- | |
# Rationale | |
On [Date], the core team decided to **(TBD)** this proposal. | |
When the core team makes a decision regarding this proposal, | |
their rationale for the decision will be written here. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment