Xcode-beta (7A152u): Protocol "inheritence" needs better access controls
Originator: | owensd | ||
Number: | rdar://21850541 | Date Originated: | 16-Jul-2015 12:13 AM |
Status: | Open | Resolved: | |
Product: | Developer Tools | Product Version: | Xcode-beta (7A152u) |
Classification: | Enhancement | Reproducible: | Always |
A protocol (this isn’t really limited to protocols though) really needs a way to separate the API for the consumers of the protocol and the implementors of the protocol. Take this example: protocol KeyValueCodable : _KeyValueCodable { mutating func setValue<T>(value: T, forKey: String) throws func getValue<T>(forKey: String) throws -> T } protocol _KeyValueCodable { static var _codables: [KVCTypeInfo] { get } var _kvcstore: Dictionary<String, Any> { get set } } extension KeyValueCodable { mutating func setValue<T>(value: T, forKey: String) { // default implementation goes here... } func getValue<T>(forKey: String) -> T { // default implementation goes here... } } Everything prefixed with “_” is “private to consumers, public to implementors”. As the protocol author, I absolutely do **not** want this to be possible: var kvc = SomeKVCType() kvc._kvcstore["haha"] = "this shouldn’t happen…" However, I need those exposed to create default implementations. This bug is probably a duplicate of many others describing how the access modifiers we have today really are not sufficient. This is an area that C++ came closer to being correct on.
Comments
Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!