[swift-evolution] [Discussion] A Problem With SE-0025?

[Adrian Zubarev]

Shouldn’t it act theoretically something like this:

// Begin file A (which acts like a scope)

// where `type` can be enum, struct, class or protocol
private type X {}  

fileprivate type Y {}

public struct Z {
     
    var x: X
    var y: Y
}
// End file A
private should always behave the same as fileprivate on the same scope level of declaration, where fileprivate is accessible from anywhere within the same file no matter in which level it was declared.

// Begin file A (which acts like a scope)

public struct Z {
     
    fileprivate var a = 0
    private var b = "z"
}

public struct X {
     
        static func foo() {
             
            var z = Z()
            z.a // a is visible here
            z.b // raises an error because b is not visible from that scope
        }
}
// End file A
That how I imagine this to work.



-- 
Adrian Zubarev
Sent with Airmail

Am 15. Juni 2016 um 20:32:09, Robert Widmann via swift-evolution (swift-evolution at swift.org) schrieb:

While implementing SE-0025 (fileprivate), I noticed an interesting bug in the proposal. Under the implementation outlined there, any top-level structure, class, or enum declared private cannot possibly be instantiated and so cannot be used in any way. Because of this, private top-level declarations are more often than not blown away entirely by the compiler for being unused. It seems strange to me to allow a key language feature to act solely as a hint to the optimizer to reduce the size of your binary. Perhaps the restrictions around private needs to be relaxed or the line between fileprivate and private needs to be investigated again by the community before inclusion in the language.

Thoughts?

~Robert Widmann
_______________________________________________
swift-evolution mailing list
swift-evolution at swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160615/1f70657b/attachment.html>