<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">I agree with all of this, and I lack strong feelings about whether this should be restricted to the same compilation unit or allowed in multiple compilation units.</div> <div id="bloop_sign_1490371906798036224" class="bloop_sign"></div> <br><p class="airmail_on">On March 23, 2017 at 1:12:51 PM, Charles Srstka via swift-evolution (<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>MOTIVATION:<br><br>In current Swift, a pattern has emerged among some developers, in order to logically group parts of a class or struct’s declaration, particularly around protocols:<br><br>class Foo {<br> …<br>}<br><br>extension Foo: SomeProtocol {<br> ...<br>}<br><br>extension Foo: SomeOtherProtocol {<br> ...<br>}<br><br>This has certain appealing characteristics; in addition to the obvious organizational property, this pattern also keeps protocol implementations close to the declaration of conformance to the protocol. Unfortunately, there are a couple of problems:<br><br>1. Extensions cannot contain stored properties. This means that if a protocol requires a property, and it makes sense for that property to be stored, its conformance cannot be completely contained within the extension, but rather some of it must be in the main declaration.<br><br>2. It’s not uncommon for these protocol conformances to need access to the type’s private internal state, but extensions do not have access to private members within the state. This necessitates declaring the needed state as fileprivate rather than private, a fact has been a primary rallying point in the battle that’s currently raging on this mailing list over whether we should keep the ‘private’ access modifier, and which I would surmise is probably the major remaining use of ‘fileprivate’ in modern Swift code.<br><br>3. Since members that are declared ‘fileprivate’ cannot be accessed outside the file, these protocol conformance extensions must belong to the same file as the original declaration, which can lead to very long file sizes when the code to implement a protocol is very long, or when a type supports a large number of protocols.<br><br>PROPOSED SOLUTION:<br><br>Add a keyword to declare only part of a type’s implementation. I am suggesting ‘partial’ as the keyword, but this can be changed for a better name if needed. Partial conformances would be declared like this:<br><br>class Foo {<br> private func somePrivateMethod() { … }<br>}<br><br>partial Foo: SomeProtocol {<br> var someRequiredProperty: Int = 5<br><br> func someRequiredMethod() {<br> self.somePrivateMethod()<br> }<br>}<br><br>partial Foo: SomeOtherProtocol {<br> func someOtherRequiredMethod() {<br> self.somePrivateMethod()<br> }<br>}<br><br>When compiling this, the compiler would simply treat all the contents of partial declarations as if they were located within the original declaration, making the above equivalent to this:<br><br>class Foo: SomeProtocol, SomeOtherProtocol {<br> private func somePrivateMethod() { … }<br><br> var someRequiredProperty: Int = 5<br><br> func someRequiredMethod() {<br> self.somePrivateMethod()<br> }<br><br> func someOtherRequiredMethod() {<br> self.somePrivateMethod()<br> }<br>}<br><br>Obviously, partial declarations would only be allowed within the same module (or submodule, once we get them) as the original declaration.<br><br>The advantages to this approach are:<br><br>1. Given a pattern that many developers are adopting, this proposal would provide a mechanism to follow that pattern properly instead of repurposing a mechanism—extensions—which was intended for something else. The Swift manual claims that extensions are meant to add things “to a type that is declared elsewhere, or even to a type that you imported from a library or a framework,” not for separating your own code into parts.<br><br>2. Partial implementations can now implement the entirety of a protocol, including stored properties if the protocol necessitates them.<br><br>3. Since the contents of all partial implementations are considered to be part of the same declaration, the contents of partial implementations can access private members, which should allow the almost complete elimination of ‘fileprivate’ from developers’ codebases, simplifying the access control model.<br><br>4. Since partial implementations are not dependent on file-based organization, they can be stored in separate files, as long as those files are compiled into the same module, thus allowing for smaller, leaner, source files that are easier to read and understand.<br><br>What do you think?<br><br>Charles<br><br>_______________________________________________<br>swift-evolution mailing list<br>swift-evolution@swift.org<br>https://lists.swift.org/mailman/listinfo/swift-evolution<br></div></div></span></blockquote></body></html>