> On Mar 23, 2017, at 2:15 PM, Matthew Johnson <[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.
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
