No please no, the ship is long sailed for this one. I wish I didn‘t messed up my proposal last year and that we completely got rid of the access modifiers before the `extension` keyword.
Huge -1 -- Adrian Zubarev Sent with Airmail Am 28. September 2017 um 19:44:25, James Valaitis via swift-evolution (swift-evolution@swift.org(mailto:swift-evolution@swift.org)) schrieb: > > When declaring a public class or struct the properties still default to > internal. > ``` > public final class NewType { > /// This property defaults to internal. > var property: Any? > } > ``` > > This is not the same for a public extension on the type, where then the > access modifier is respected for any function or calculated property within > the extension. > ``` > public extension NewType { > /// This function inherits the public modifier. > func function() { > } > } > ``` > > I dislike this inconsistency, and I frequently find that when using my > dynamic frameworks my code will not compile, and it will be due to my > accidentally writing a public struct but not declaring the properties public. > > I believe in the idea that explicitly stating the access modifier leads to > more legible code, but in my opinion it can be overdone, and I much prefer to > explicitly state my intentions in the modifier on the definition or > extension. For example: > > ``` > public struct Coordinate { > /// Should default to public. > let latitude: Double > /// Should default to public. > let longitude: Double > /// Should default to public > init?(latitude: Double, longitude: Double) { > guard validate(latitude: latitude, longitude: longitude) else { return nil } > … > } > } > internal extension Coordinate { > /// Convenience initialiser to me used internally within the module. > init(coordinate: CLLocationCoordinate2D) { > … > } > } > private extension Coordinate { > /// Private validation of the coordinate. > func validate(latitude: Double, longitude: Double) -> Bool { > … > } > } > ``` > > This is legible and intuitive. The current behaviour is not. > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
