> Also, while some have mentioned that this adds complexity to the access
> control system because types are now a factor, to that I say: this is purely
> a theoretical issue. In practice, developers don't care that this is case,
> and just care that the access control logic makes sense when using it. As
> someone who's had to explain why fileprivate is necessary many times to new
> Swift developers when using extensions, I can assure you that using this
> proposed private definition makes more intuitive sense to them.
Well, I guess than it would be the best to ignore private completely and only
teach the model of Swift 2:
Without private, access control is completely separated from from extensions
(mixing concerns rarely makes things easier), and you save yourself from the
questions why extension A can't see a property declared five lines above,
wheres extension B at the bottom of the same file has no such problem.
No one really knows what's better for the "average Swift programmer", and no
matter how many newcomers you have met, I doubt it is a significant share of
all Swift users out there.
Sticking to facts, we have a steady increase of access control complexity, and
this is pepped by adding special rules to work around perceived or real
inconveniences.
SE-0169 aims to be a small change with minimal impact, but those pile up
easily...
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
