I am grad if it is accepted. I have two reasons.
(1) I just recently confused visibility rule of extension which is different from class/struct. (2) I often write many classes in only one application target in project first. After code base grow, I often make new Framework target and move some classes into this for organizing dependency and improving modularity. At that time I need to write may `public` for classes and each func and vars. This is boring work. If I need to write `public` only once for each classes, It is very convenient. -- omochimetaru 2017年9月29日(金) 10:05 Jonathan Hull via swift-evolution < swift-evolution@swift.org>: > I should also mention that this is from a class of error where it becomes > more likely with expertise. Thus, the more you do it, and get used to > doing it, the more your brain will automate the task. You see this type of > thing pretty often with nurses, for example. > > For anyone who would like a better understanding of the science behind > designing to prevent errors, I recommend the book *“Human Error” *by* > James Reason*. > > Also *"The Design of Everyday Things" *by* Don Norman* has a pretty good > chapter on the basics, and is much more accessible. > > I really like that Swift attempts to do this! The use of forcing > functions around optionals, for example, is brilliant. It is just that we > are applying solutions rather haphazardly (without matching them to the > underlying cause of error), and I think we can do better. That we are even > considering these things is huge! I am just saying that there is an entire > body of scientific research we can use to effectively accomplish this goal > (and avoid known pitfalls)… we don’t have to reinvent the wheel. > > Thanks, > Jon > > > On Sep 28, 2017, at 5:31 PM, Jonathan Hull via swift-evolution < > swift-evolution@swift.org> wrote: > > +1000 > > This is the way it always should have worked… and it is the way my brain > still expects it to work. All of the extraneous “Public”s clutter the code > and make it much more difficult to read. Without it, the relatively few > properties marked Internal or Private stand out. > > I know there is the argument about making people think about whether they > want to expose each item… but it doesn’t work that way. Once you assign > someone a rote task (assigning Public to most of the things), you lose the > effect of having them think. From a cognitive psychology lens, when you > give the brain a number of decisions to make in a row that are very > similar, it will naturally make that task more efficient by automating as > much of it as possible (i.e. thinking about it less). Mistakes become much > more likely as a result. > > Tl;dr: Despite the* myth*/intention that the current setup makes you* > think about the problem more,* it actually does the* opposite* and leads > to an *increased risk of error*. > > Thanks, > Jon > > > On Sep 28, 2017, at 10:44 AM, James Valaitis via swift-evolution < > swift-evolution@swift.org> wrote: > > 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 > > > _______________________________________________ > 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