[swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Drew Crawford]

True indeed… but can we agree that this is just an hypothetic example, and no issue that is likely to happen in productive code?
Or is this actually taken from one of the projects you measured?
Here is the expanded edition which is productive.

/**A dummy return value to indicate a method isn't threadsafe.
 Because unused return values produce warnings in Swift, a caller who uses the method absentmindedly will have a warning in their code.  This can be suppressed with `let _: NotThreadSafe` from the caller. */
struct NotThreadSafe { }

///There are many cache implementations with different performance characteristics.
///we model them with a protocol.
protocol CacheImplementation {
    func prune() -> NotThreadSafe
}

///Many components share a single cache, so we expose it as a reference type
class Cache {
    
    init() { preconditionFailure("Provide a constructor to satisfy the compiler") }
    private var v: CacheImplementation
    private let lock = DispatchQueue(label: "lock")
    
    
    private func prune() -> NotThreadSafe {
        v.prune()
        return NotThreadSafe()
    }
    ///expose a threadsafe API to callers
    internal func prune() {
        lock.sync {
            //supress the warning, since we have a lock.
            let _: NotThreadSafe = self.prune()
        }
    }
}

extension Cache {
    func pruneAgressively() {
        for _ in 0..<5 {
            self.prune()
        }
    }
}

Note that, in this example, the scoped access keyword actually makes extensions *easier*, not harder, to write, because the extension does not need to choose between a safe and unsafe version of the method.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170321/778198e7/attachment.html>