> 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

Reply via email to