> On Mar 23, 2017, at 2:37 PM, Charles Srstka <[email protected]> wrote: > >> On Mar 23, 2017, at 2:15 PM, Matthew Johnson <[email protected] >> <mailto:[email protected]>> 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.
Sure, but this does effectively violate lexical scope boundaries as they exist in the original source. > > You can also think of the “Foo_Private.h” headers that can be shared amongst > several different files in Objective-C. > > Charles >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
