[swift-evolution] Simplifying Access Using 'Hidden'

[Adrian Zubarev]

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 (razielim at gmail.com) schrieb:


On 13 Feb 2017, at 17:21, Adrian Zubarev via swift-evolution <swift-evolution at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170213/ad786b2b/attachment.html>