Well summarised Tino, I agree with all arguments.
Strong -1 from me, too.
> Am 11.04.2017 um 08:48 schrieb Tino Heth via swift-evolution
> <[email protected]>:
>
> -1 (strong)
>
> I think I've read all messages and haven't much to add — so just to sum up my
> concerns in order:
> — It makes access control more complicated
> — It adds no power to the language
> — It diminishes the need for fileprivate without making it redundant
> — It is a mockery for SE-0025
> — It is a breaking change
If we want to encourage separating several aspects of one type into multiple
extensions, then we should try a different approach.
When we allow to also introduce new member variables in extensions, then we
could make them private while still keeping them local to the member functions
which access them.
This approach has other downsides but I think we can cope with them.
Biggest disadvantage would be that the storage size is not immediately visible
from the type definition.
We could require some marker (`partial class` / `extension class` / whatever)
so that everybody can immediately see that there may be extensions with
additional storage.
E.g.:
partial class Foo {}
extension Foo {
private var i = 0
func bar() {
print(i)
i += 1
}
}
extension Foo {
private var j = 1
func baz() {
print(j)
j -= 1
}
}
When we want any distinction between `private` and `fileprivate`, then these
two extensions should not see each others private members.
Of course the other workaround would be to remove the distinction altogether
and make private an alias for fileprivate.
—
Martin
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
