> On 14 Oct 2016, at 09:35, Jamie Lemon via swift-evolution > <swift-evolution@swift.org> wrote: > > I agree with Ted that I would have expected the inner members of a class to > be private by default. (Not a big deal if I have to explicitly prefix most of > my concerned vars now - but it is just different to what I would have > expected). Certainly, in the past, I would be more used to having to > explicitly define chosen vars as “public” ( e.g. in the past world of > Objective C I was used to defining selected vars with @synthesize to “open > them up" )
@synthesize has nothing to do with instance variable visibility, all it did was synthesise an instance variable to back a property (which was really a pair of methods). In Objective-C instance variables are protected (i.e. visible to subclasses) by default and all methods (which by extension means properties too) are public. The waters are somewhat muddied by the fact that the Objective-C compiler can only see declarations in the current code unit and any imports, so you can hide non private instance variables by putting them in the @implementation and you can hide properties and methods by declaring them in a category that isn’t in an import. However, anybody can defeat the second of these by declaring their own category with the hidden method signatures in it. private by default is comparatively rare, it’s not true of Java, C#, Javascript, or Python. Having said, that it does make sense to me but would be an enormous breaking change for Swift now. I was against the private/fileprivate distinction when it was proposed, but now it’s done and I’ve applied it to my own code, I am fine with it. I did a global replace of fileprivate with private in one of my largest converted source files and experienced only one breakage. I think there is a use case for fileprivate, so I wouldn’t want to get rid of it but I think it’s rare enough that the ugliness of its name doesn’t bother me. > > _______________________________________________ > 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
