|
| 1 | +--- |
| 2 | +layout: post |
| 3 | +title: ! 'Issue #191' |
| 4 | +author: fassko |
| 5 | +--- |
| 6 | + |
| 7 | +Have you noticed how the last two weeks have been pretty low-key for the Swift community? I feel this is a lull before the storm of September comes and we all know what that means. Folks are holding their breath, eager to find out news from Apple. |
| 8 | + |
| 9 | +Personally, this time is quite challenging for me as I am getting ready to take the stage at [360iDev conference](https://360idev.com/). Unfortunately, the US hasn't opened their borders yet, even for fully vaccinated people, so I’m participating online this time. But despite not being able to meet old friends and make new friends in person, I'm truly looking forward to connecting with people and sharing my experience using Swift for rapid development. Let me know if you’re participating in 360iDev and let’s meet up! |
| 10 | + |
| 11 | +For those of you who want to give back to community and support the Swift Weekly Brief, we are open for [sponsors](https://swiftweeklybrief.com/sponsorship/). |
| 12 | + |
| 13 | +<!--excerpt--> |
| 14 | + |
| 15 | +{% include sponsor.html %} |
| 16 | + |
| 17 | +### Starter tasks |
| 18 | + |
| 19 | +> [SR-15026](https://bugs.swift.org/browse/SR-15026) [Compiler] Fix-it for deprecated initializers removes the `.init` part from `self.init` |
| 20 | +
|
| 21 | +### News and community |
| 22 | + |
| 23 | +[Collin Donnell](https://twitter.com/collindonnell) [tweeted](https://twitter.com/collindonnell/status/1420950032669286402) that Swift is the only language they could find with over 100 keywords. |
| 24 | + |
| 25 | +[Khawer Khaliq](https://twitter.com/khawerkhaliq) wrote [a blog post](https://khawerkhaliq.com/blog/swift-optional-chaining/) explaining the power of optional chaining in Swift. |
| 26 | + |
| 27 | +[Antoine van der Lee](https://www.twitter.com/twannl) has [created a great resource](https://www.avanderlee.com/#h-swift-keywords) about Swift keywords. |
| 28 | + |
| 29 | +[Ayman Fayez](https://aymanmoo.medium.com/) wrote [a post](https://aymanmoo.medium.com/copy-on-assignment-vs-copy-on-write-in-swift-c3016b343d06) about copy-on-assignment vs. copy-on-write in Swift. |
| 30 | + |
| 31 | +Excellent [writeup](https://t.co/ahsYLaO8lZ?amp=1) covering all of Swift’s internal underscored attributes by [Varun Gandhi](https://twitter.com/typesanitizer). |
| 32 | + |
| 33 | +### Proposals in review |
| 34 | + |
| 35 | +[SSE-0320](https://github.com/apple/swift-evolution/blob/main/proposals/0320-codingkeyrepresentable.md): *Coding of non `String` / `Int` keyed `Dictionary` into a `KeyedContainer`* is [under review](https://forums.swift.org/t/se-0320-coding-of-non-string-int-keyed-dictionary-into-a-keyedcontainer/50903). |
| 36 | + |
| 37 | +> The current conformance of Swift's `Dictionary` to the `Codable` protocols has a somewhat-surprising limitation in that dictionaries whose key type is not `String` or `Int` (values directly representable in `CodingKey` types) encode not as `KeyedContainer`s but as `UnkeyedContainer`s. This behavior has caused much confusion for users and I would like to offer a way to improve the situation. |
| 38 | +> |
| 39 | +> Swift-evolution thread: [[Pitch] Allow coding of non-`String`/`Int` keyed `Dictionary` into a `KeyedContainer`](https://forums.swift.org/t/pitch-allow-coding-of-non-string-int-keyed-dictionary-into-a-keyedcontainer/44593) |
| 40 | +
|
| 41 | +### Swift Forums |
| 42 | + |
| 43 | +[Cal Stephens](https://twitter.com/calstephens98) pitched [a proposal](https://forums.swift.org/t/guard-capture-specifier-for-closure-capture-lists/50805) introducing a `guard` capture specifier for closure capture lists. |
| 44 | + |
| 45 | +> In some classes of Swift programming, such as UI programming, closures are a predominant way to perform action handling and send event notifications between multiple objects. When passing closures between parent objects and their children, special care must be taken to avoid retain cycles. |
| 46 | +> |
| 47 | +> `weak` captures are often the preferred method to avoid retain cycles. In action handling and event notification closures, there is typically no work to perform if `self` (or other captured objects) no longer exist. Because of this, a large number of these closures simply `guard` that the weakly captured object still exists, and otherwise do nothing. |
| 48 | +
|
| 49 | +[Johannes Auer](https://forums.swift.org/u/jmjauer) started [a thread] about `AnyAsyncSequence` in Swift. |
| 50 | + |
| 51 | +Swift on the Server Workgroup meeting notes: |
| 52 | + |
| 53 | +* [July 7th 2021](https://forums.swift.org/t/july-7th-2021/50960) |
| 54 | +* [July 21st 2021](https://forums.swift.org/t/july-21st-2021/50961) |
| 55 | + |
| 56 | +[Benjamin Driscoll](https://forums.swift.org/u/bdriscoll) pitched [an idea](https://forums.swift.org/t/structural-opaque-result-types/50998) to add structural opaque result types. |
| 57 | + |
| 58 | +> An opaque result type may be used as the result type of a function, the type of a variable, or the result type of a subscript. In all cases, the opaque result type must be the entire type. This proposal recommends lifting that restriction and allowing opaque result types in "structural" positions. |
| 59 | +> |
| 60 | +> We should allow opaque result types in structural positions in the result type of a function, the type of a variable, or the result type of a subscript. |
| 61 | +
|
| 62 | +[mattt](https://twitter.com/mattt) [pitched a proposal](https://forums.swift.org/t/package-registry-service-publish-endpoint/51067) that would add a publish endpoint to the package registry service. |
| 63 | + |
| 64 | +> A package registry is responsible for determining which package releases are made available to a consumer. |
| 65 | +> |
| 66 | +> Currently, the availability of a package release is determined by an out-of-band process. For example, a registry may consult an index of public Swift packages and make releases available for each tag with a valid version number. |
| 67 | +> |
| 68 | +> Having a standard endpoint for publishing a new release to a package registry would empower maintainers to distribute their software and promote interoperability across service providers. |
| 69 | +
|
| 70 | +[Nicholas Maccharoli](https://forums.swift.org/u/nicholas_maccharoli) [purposed](https://forums.swift.org/t/if-guard-shorthand-for-optional-unwrapping/51088) a shordhand solution for optional unwrapping. |
| 71 | + |
| 72 | +[Vihan Bhargava](https://twitter.com/vihanbh) wrote an aweseome overview of the new `SortedDictionary` and `SortedSet` APIs bring brought to swift-collections. |
| 73 | + |
| 74 | +> The Swift Collections package currently includes two data structures which maintain its members in a well-defined order: `OrderedSet` and `OrderedDictionary`. These types are useful in a variety of use-cases, as they enumerate their elements in insertion order. However, there also exist many situations where its desired to maintain elements in an order specified by a predefined comparator. For example, a common pattern in user interfaces is displaying a list with entries sorted in some order, such as in chronological order. |
| 75 | +> |
| 76 | +> Quick ad hoc implementations of sorted data structures can have many pitfalls. A naive implementation can devolve to quadratic performance. A smarter implementation using binary search is difficult to get correct and has subtle potential pitfalls. For this reason, there is natural place to provide high-performance, production-grade sorted data structures. |
| 77 | +
|
| 78 | +[Andrew Trick](https://forums.swift.org/u/andrew_trick/) pitched [an idea](https://forums.swift.org/t/pitch-implicit-pointer-conversion-for-c-interoperability/51129) to add an implicit pointer conversion for C interoperability. |
| 79 | + |
| 80 | +> C has special rules for pointer aliasing, for example allowing `char *` to alias other pointer types, and allowing pointers to signed and unsigned types to alias. The usability of some C APIs relies on the ability to easily cast pointers within the boundaries of those rules. Swift generally disallows typed pointer conversion. See [SE-0107 UnsafeRawPointer API](https://github.com/apple/swift-evolution/blob/main/proposals/0107-unsaferawpointer.md). Teaching the Swift compiler to allow pointer conversion within the rules of C when invoking functions imported from C headers will dramatically improve interoperability with no negative impact on type safety. |
| 81 | +
|
| 82 | +[Brennan Stehling](https://forums.swift.org/u/brennanmke) purposed to add the throw coalescing operator to the Swift language. |
| 83 | + |
| 84 | +> I'd really like syntax for `do`/`try`/`catch` which is as compact as `nil` coalescing in Swift. And so I put together a working implementation which I'd like to refine further. So far I have `!!` defined as my operator much like `??` for `nil` coalescing so it is familiar. The left operand would the work while the right would handle the error. |
| 85 | +
|
| 86 | +### Finally |
| 87 | + |
| 88 | +* [Is your child texting about C++?](https://twitter.com/omershapira/status/1424592236537339907) |
| 89 | +* [maccinated](https://twitter.com/jckarter/status/1425110878504984577) |
0 commit comments