[swift-evolution] Pitch: Partial Implementations

[Charles Srstka]

> On Mar 23, 2017, at 2:15 PM, Matthew Johnson <matthew at anandabits.com> wrote:
> 
> What I’m suggesting is that we could accomplish the same functionality by enhancing extensions.  You can make a case that using a different keyword for same-module extensions that are allowed to have stored properties is a good idea.  I’m not sure I would support that though.

The problem is that people are using extensions to implement part of the original class definition. Part of what is making that pattern awkward is that private members are not accessible from the extensions. Given the SE-0159 discussion, it appears that there is a non-negligible threat of losing the very ability to have scoped members at all if we don’t think of a better alternate solution.

>> 2) I’m not proposing changing the meaning of ‘private’ here. Since partial implementations would all glom into one lexical scope, all the current access control rules would apply as they currently do. This is simply a way to write a class or struct declaration in multiple parts, without having to use extensions.
> 
> This does not fit with any definition of “lexical scope” I am familiar with.  I wouldn’t want to see Swift adopt this definition of lexical scope.

No definitions required. All I’m proposing is basically preprocessing the thing into one type declaration.

class Foo {
	func bar() {}
}

partial Foo {
	func baz() {}
}

just becomes syntactic sugar for:

class Foo {
	func bar() {}
	func baz() {}
}

After this conversion, bar and baz are in the same lexical scope. No new definitions of anything are required.

You can also think of the “Foo_Private.h” headers that can be shared amongst several different files in Objective-C.

Charles

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170323/395a8160/attachment.html>