> On 11 Apr 2017, at 08:48, Tino Heth via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> -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
> For me, it's not about the complexity itself (it's not terrible huge, after
> all), but I believe in the beauty of simplicity, which is already quite
> flawed.
> — It adds no power to the language
> The proposal solves no real problem, but rather encourages a certain style of
> programming, which is quite popular among authors of styleguides, but has no
> clear net gain.
While your other points are defendable, I have to disagree here. It does bring
value to a population of developers (me included) for whom that style of
programming adds a lot of readability. It's part of style guides for a reason.
> — It diminishes the need for fileprivate without making it redundant
> It would be nice to get rid of an access level, but having four common ones
> and fileprivate as an exotic outlier doesn't feel right for me.
Doesn't the argument of progressive disclosure sway you here? open is already
an outlier that only library authors will play with, and that's a good thing.
It reduces the number of access level truly useful on a day to day basis, while
leaving the others for more narrow purposes.
> — It is a mockery for SE-0025
> I never liked "new private", but it was decided that this sort of
> encapsulation is important enough to justify 33% increase in the number of
> access levels, so I don't like to see this watered down
> — It is a breaking change
> For me personally, that doesn't really count as an argument on its own, and I
> would gladly take the inconvenience of incompatibility in exchange for a tiny
> improvement of the language; but in combination with the other points, it
> increases opposition.
>
> I spend some time thinking about nested extensions (which would achieve the
> goal of this proposal naturally) and think that SE-0169 would lead to some
> questionable possibilities of short-circuiting access control:
>
> class Outer {
> private class Inner {
> private var x = 0
> }
> }
>
> /*
> .
> .
> .
> */
>
> extension Outer.Inner {
> public func f() {
> print(x)
> }
> }
>
> As I read the proposal, there is no doubt that this would be allowed — but
> without that detailed information, I'm not sure if anybody would expect that
> two levels of private still is not enough to keep something secret…
>
> - Tino
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
