A short but sweet issue this week. Sorry for the cliché — but it’s true!
Are you a mobile developer with 4+ years of experience, proficient in Objective-C or Swift and can help develop mobile applications? If so, we are interested in speaking with you! Contact us using the link provided.
News and community
Apple released Xcode 10.2.1.
The core team agrees that this proposal lays important groundwork that can be built on further in ways laid out in the author’s Generics UI Improvements overview. This write-up helped clarify the context of the proposal both for reviewers and the core team itself.
Several reviewers felt that being able to name opaque types is an important feature for many use cases. This is clearly a useful feature and would be a good next step, but the core team thinks that the feature as proposed consists of a reasonable “minimum viable product” to land now, and then can be added to through subsequent proposals.
The core team is very positive about the idea of this feature, but would like to see some changes to the proposal, followed by another round of public review. As such, the proposal is returned for revision.
The Core Team did not feel the motivation behind the proposal warranted expanding the
Collectionprotocol hierarchy. The
Collectionhierarchy is already quite rich, and any motivation to expanding it in the Standard Library needs to meet a high bar in general utility. At this time the proposed change was deemed too niche to motivate that change.
Proposals in review
There are property implementation patterns that come up repeatedly. Rather than hardcode a fixed set of patterns into the compiler, we should provide a general “property delegate” mechanism to allow these patterns to be defined as libraries.
This is an alternative approach to some of the problems intended to be addressed by the 2015-2016 property behaviors proposal.
Swift requires a semicolon “
;” to separate statements unless those statements are separated by newlines, in which case the semicolon can be elided. Currently, Swift requires a comma “
,” to separate expressions even when those statements are separated by newlines. We should ease this restriction, allowing the comma between two expressions to be elided when they are separated by a newline.
Swift currently supports marking declarations with compiler-defined attributes, such as
@deprecated. The compiler uses these attributes to customize the way it interprets the corresponding code. As a first step towards opening attributes to users and library authors, this proposal introduces static custom attributes which exist only at compile time, allowing tools that parse Swift code to use them as markers.
I mean, why not?