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

[Adam Kemp]

> On Nov 7, 2017, at 6:05 PM, Jon Gilbert via swift-evolution <swift-evolution at swift.org> wrote:
> 
> It’s easy to have projects where one Swift module is made up of numerous git repos. You can silo who is allowed to touch your code that way even within people working on a single module.

Why do you need to have multiple git repos contribute to a single module instead of having each repo produce its own module? I don’t understand why you would do that.

To me “module” implies “a cohesive set of code maintained by a single team”. I trust people on my team, and I can also see every change that goes into the projects I work on.

Again, if you don’t trust developers that are contributing code to your module then you have bigger problems than this. Proper module boundaries would help to address those problems.

> Having a class “partial” where anyone in the module can screw around is dangerous and therefore un-Swifty. 

This is contradicted by the experience of a large community of C# developers who have been using partial classes for years without running into your hypothetical problems.

A search on GitHub shows over 5 million hits for “partial class” in C# code:
https://github.com/search?l=C%23&o=desc&q=%22partial+class%22&s=indexed&type=Code <https://github.com/search?l=C#&q="partial+class"&type=Code>

There are over 2000 hits in the Rosyln codebase alone (Microsoft’s C# compiler):

https://github.com/dotnet/roslyn/search?q=%22partial+class%22&type= <https://github.com/dotnet/roslyn/search?q=%22partial+class%22&type=>

This is heavily used in the real world by professionals working on projects of all sizes.

I think we have to weigh the FUD against what we can observe actually happening in the wild when developers use a feature like this. The reality is that the things you’re concerned about are not actually problems in practice. They’re contrived hypotheticals.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171107/614876c3/attachment.html>