I’ve never said, I liked the keyword by its name, however I do like its behavior which opens up flexible ways of creating some code dependency across the file. What I really meant is, that I feel like some people talk about fileprivate behavior as if it was new, which it is not.
I’m feeling with you about private(file), but I’m not sure about private(module), because internal is shorter and seems fine to me. ;) -- Adrian Zubarev Sent with Airmail Am 13. Februar 2017 um 17:35:42, Karl Wagner (razie...@gmail.com) schrieb: On 13 Feb 2017, at 17:21, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote: People talk always like “I never liked fileprivate” and I feel like some of you forgot that fileprivate is not new to Swift. It’s the repainted private from days before Swift 3. I cannot recall anyone complaining about it that much. There were some people that forced the addition of a stricter private access modifier for Swift 3. Now that we have both, there are a lot of complains about fileprivate. It _is_ kind of ugly. I would support rearranging our access lives like this, with a parameterised “private”: open public private(module) // today’s “internal” private(file) // today’s “fileprivate” private // today’s “private” It also opens the door to more nuanced access levels, such as private(type) to allow access to the hidden member in cross-file extensions but not generally throughout the module. For properties, it would mean public internal(set) var something: Bool would become public private(module, set) var something: Bool at which point it might be nicer to flip the arguments and call it “setter”: public private(setter, module) var something: Bool - Karl
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
