[swift-evolution] continuations - "extensions on steroids" idea

Adam Kemp adam_kemp at apple.com
Fri Nov 3 11:42:19 CDT 2017

> On Nov 3, 2017, at 5:17 AM, Mike Kluev <mike.kluev at gmail.com> wrote:
> On 3 November 2017 at 03:05, Adam Kemp <adam.kemp at apple.com <mailto:adam.kemp at apple.com>> wrote:
> Would it be an error to have an entry in the “ledger” but not a corresponding implementation?
> definitely so. and vice versa.
> Mike

If that’s the case then this wouldn’t solve one of the major use cases I listed for this: splitting up cross-platform classes into platform-specific files. The idea is that each target contains a different subset of the files. Consider a case where two platforms are similar enough to share some code but not all code. For instance:

Class.UIKit.swift // Used by iOS + watchOS

There are three targets, and two of the targets include Class.UIKit.swift but not the third. So what do you put in the ledger?

For a real-world example, consider a custom view that is used for presenting content in an app that shares code on iOS, tvOS, and macOS. Much of the logic for this is shared, including rendering which is done using CoreGraphics. You could write that class something like this:

import CoreGraphics

partial class PresentationView {

private func draw(inContext context: CGContext) {
// Shared CoreGraphics drawing


PresentationView.UIKit.swift: // Used by iOS + tvOS
import UIKit

partial class PresentationView : UIView {
func draw(_ rect: CGRect) {
self.draw(inContext: UIGraphicsGetCurrentContext())

import AppKit

partial class PresentationView : NSView {
func draw(_ dirtyRect: NSRect) {
self.draw(inContext: NSGraphicsContext.currentContext()?.CGContext)

This is exactly the technique that I’ve used in the past (in C#) to share code across iOS, Android, macOS, and WPF. It’s really powerful, but the ledger would make it much harder.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171103/b878ef1d/attachment.html>

More information about the swift-evolution mailing list