Update README, process, and proposal template for Swift 4 stage 1. #541
Conversation
DougGregor
force-pushed
the
swift-4-updates
branch
from
a4a1e1a
to
3d0fc6b
Compare
DougGregor
force-pushed
the
swift-4-updates
branch
from
3d0fc6b
to
93a22dd
Compare
| break source compatibility if the Swift 3 constructs were actively | ||
| harmful in some way, the volume of affected Swift 3 code is relatively | ||
| small, and we can provide source compatibility (in Swift 3 | ||
| compatiblity mode) and migration. |
| with the Swift runtime, including such things as calling conventions, | ||
| the layout of data types, and the behavior of dynamic features in the | ||
| language (reflection, dynamic dispatch, dynamic casting via `as?`, | ||
| etc.). Purely syntactic changes rarely affect existing ABI. Additive |
There was a problem hiding this comment.
Most of the time, you'll want affect as a verb meaning to influence something and effect for the something that was influenced. The difference between affect and effect is so slippery that people have started using "impact" as a verb instead. Don't be one of them!
There was a problem hiding this comment.
"effect on ABI" ⇒ "affect [the] ABI". 😄
There was a problem hiding this comment.
I'll just strike the words "affect" and "effect" from the English language and save us all some time.
| other high-performance applications that want predictible and | ||
| deterministic performance. This feature will fundamentally shape the | ||
| ABI, from low-level language concerns such as "inout" and low-level | ||
| "addressors" to its impact on the standard library. |
There was a problem hiding this comment.
I'd suggest mentioning that we need to get a design of this, which will allow us to scope the small part that effects the ABI and make sure that happens in Stage 1.
There was a problem hiding this comment.
IOW, ownership as a whole is not a stage 1 feature.
| "addressors" to its impact on the standard library. | ||
|
|
||
| ## Swift 3.0 - Released on September 13, 2016 | ||
|
|
There was a problem hiding this comment.
Would it make sense to break descriptions of historical releases out to a separate page? We could have a "Swift 3" page, which lists its raison d'etre, along with the SE's that went into it.
There was a problem hiding this comment.
Yeah, I like that better. It keeps the README shorter and more forward-looking.
|
This looks really great Doug, I added a few comments to the patch. |
| Will existing correct Swift 3 or Swift 4 applications stop compiling | ||
| due to this change? Will applications still compile but produce | ||
| different behavior than they used to? If "yes" to either of these, is | ||
| it possible for the Swift 4 compiler to accept the old syntax in it's |
|
|
||
| Stage 1 focuses on the essentials required for source and ABI | ||
| stability. Features that don't fundamentally change the ABI of | ||
| existing language features or imply and ABI-breaking change to the |
There was a problem hiding this comment.
... or imply an ABI-breaking ...
Moving out information about Swift 2.2 and Swift 3.0 allows us to be more verbody there (about which proposals were implemented in a release) and keep the README more forward-looking.
|
Nice, LGTM! Thank you for working on this. |
|
|
||
| * Memory ownership model: an (opt-in) Cyclone/Rust-inspired memory | ||
| ownership model is highly desired by systems programmers and for | ||
| other high-performance applications that want predictible and |
No description provided.