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

[Adam Kemp]

> On Nov 3, 2017, at 10:05 AM, Mike Kluev <mike.kluev at gmail.com> wrote:
> 
> On 3 November 2017 at 16:42, Adam Kemp <adam_kemp at apple.com <mailto:adam_kemp at apple.com>> wrote:
> 
> 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:
> 
>  
> i think we need a better real-world example, as in this one it's probably easier to have "View" defined as a type alias to either UIView or NSView depending upon a platform and similarly define currentGraphicsContext() to be either UIGraphicsGetCurrentContext() or NSGraphicsContext.currentContext()?.CGContext depending upon a platform and have a single code base afterwords:

When you actually try to use that technique in a fuller example it becomes impractical. I know because some people working on the same code base tried that, and it was much worse. Partial classes make for a much cleaner implementation, and they avoid conditional compilation.

I will concede that there are other techniques for cross-platform code that might be considered even cleaner. This isn’t the only technique, and I won’t claim that it’s the best technique, but it is a very useful technique that I have seen used very effectively. It would be nice to be able to have it as an option.

> having said that, yes, i can see your point. my fear is that it will be (1) too fragile (e.g. you have "TableViewDelegate" in the ledger and just forgot to include the relevant file in the target - the app compiles but then misbehaves,

My argument is that there should be no ledger in the first place. IMO you haven’t made the case for that requirement.

If you forget to implement a protocol then your build will fail because either 1) you claimed to implement it and didn’t or 2) you didn’t claim to implement it and then tried to use that class somewhere that expects an object conforming to the protocol. This was never a problem. We have a type safe language. Even if you come up with some corner case where this could actually happen it falls squarely into the realm of bugs that would never ship (i.e., it will be obvious very quickly that something is wrong).

> and (2) open for abuse.

Again, we have to trust our developers to some extent. I worked in a large codebase with a large team of developers and not once did anyone abuse this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171103/1145e8ee/attachment.html>