I missed the other code based modules conversation floating around... this would also be a much better solution imo - dropping fileprivate and having modules with open/public/internal/private seems like it would cover everything one might need without being bound to something like a physical file..
/shrug > In terms of black and white, approve or don't approve - I agree with Matt, > thumbs down on this one from me too. > > For what it's worth while I also use fileprivate a lot I dislike the > concept... I think pairing scope to something physical like a file is weird - > but I also believe it is a symptom of a flaw in the tooling. > > If Xcode supported module/framework based development as easily as IDEs like > visual studio then fileprivate would never have been needed and internal > scope would actually serve a purpose. We would have 'internal' types that can > live in their own files but would be invisible to the consumer of the > module/framework. > > _That_ would be my hope for access modifiers going forward, but unless Xcode > is open sourced I fear that we have to make language compromises like > fileprivate which as essentially a crutch imo. > > Ian Keen. _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
