<div dir="ltr"><div>I am grad if it is accepted.</div><div><br></div><div>I have two reasons.</div><div><br></div><div>(1)</div><div>I just recently confused visibility rule of extension which is different from class/struct.</div><div><br></div><div>(2)</div><div>I often write many classes in only one application target in project first.</div><div>After code base grow, I often make new Framework target and move some classes into this for organizing dependency and improving modularity.</div><div>At that time I need to write may `public` for classes and each func and vars.</div><div>This is boring work.</div><div>If I need to write `public` only once for each classes, It is very convenient.</div><div><br></div><div>--</div><div>omochimetaru</div></div><br><div class="gmail_quote"><div dir="ltr">2017年9月29日(金) 10:05 Jonathan Hull via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">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.<div><br></div><div>For anyone who would like a better understanding of the science behind designing to prevent errors, I recommend the book <b>“Human Error” </b>by<b> James Reason</b>. </div><div><br></div><div>Also <b>"The Design of Everyday Things" </b>by<b> Don Norman</b> has a pretty good chapter on the basics, and is much more accessible.</div><div><br></div><div>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.</div><div><br></div><div>Thanks,</div><div>Jon</div></div><div style="word-wrap:break-word"><div><br><div><div><br><div><blockquote type="cite"><div>On Sep 28, 2017, at 5:31 PM, Jonathan Hull via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_-259927683432541088Apple-interchange-newline"><div><div style="word-wrap:break-word">+1000<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Tl;dr: <b> </b>Despite the<b> myth</b>/intention<b> </b>that the current setup makes you<b> think about the problem more,</b> it actually does the<b> opposite</b> and leads to an <b>increased risk of error</b>.</div><div><br></div><div>Thanks,</div><div>Jon</div><div><br></div><div><br><div><blockquote type="cite"><div>On Sep 28, 2017, at 10:44 AM, James Valaitis via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_-259927683432541088Apple-interchange-newline"><div><div>When declaring a public class or struct the properties still default to internal.<br>```<br>public final class NewType {<br><span class="m_-259927683432541088Apple-tab-span" style="white-space:pre-wrap"> </span>/// This property defaults to internal.<br><span class="m_-259927683432541088Apple-tab-span" style="white-space:pre-wrap"> </span>var property: Any?<br>}<br>```<br><br>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.<br>```<br>public extension NewType {<br><span class="m_-259927683432541088Apple-tab-span" style="white-space:pre-wrap"> </span>/// This function inherits the public modifier.<br><span class="m_-259927683432541088Apple-tab-span" style="white-space:pre-wrap"> </span>func function() {<br><span class="m_-259927683432541088Apple-tab-span" style="white-space:pre-wrap"> </span>}<br>}<br>```<br><br>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.<br><br>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:<br><br>```<br>public struct Coordinate {<br><span class="m_-259927683432541088Apple-tab-span" style="white-space:pre-wrap"> </span>/// Should default to public.<br><span class="m_-259927683432541088Apple-tab-span" style="white-space:pre-wrap"> </span>let latitude: Double<br><span class="m_-259927683432541088Apple-tab-span" style="white-space:pre-wrap"> </span>/// Should default to public.<br><span class="m_-259927683432541088Apple-tab-span" style="white-space:pre-wrap"> </span>let longitude: Double<br><span class="m_-259927683432541088Apple-tab-span" style="white-space:pre-wrap"> </span>/// Should default to public<br><span class="m_-259927683432541088Apple-tab-span" style="white-space:pre-wrap"> </span>init?(latitude: Double, longitude: Double) {<br><span class="m_-259927683432541088Apple-tab-span" style="white-space:pre-wrap"> </span><span class="m_-259927683432541088Apple-tab-span" style="white-space:pre-wrap"> </span>guard validate(latitude: latitude, longitude: longitude) else { return nil }<br><span class="m_-259927683432541088Apple-tab-span" style="white-space:pre-wrap"> </span><span class="m_-259927683432541088Apple-tab-span" style="white-space:pre-wrap"> </span>…<br><span class="m_-259927683432541088Apple-tab-span" style="white-space:pre-wrap"> </span>}<br>}<br>internal extension Coordinate {<br><span class="m_-259927683432541088Apple-tab-span" style="white-space:pre-wrap"> </span>/// Convenience initialiser to me used internally within the module.<br><span class="m_-259927683432541088Apple-tab-span" style="white-space:pre-wrap"> </span>init(coordinate: CLLocationCoordinate2D) {<br><span class="m_-259927683432541088Apple-tab-span" style="white-space:pre-wrap"> </span><span class="m_-259927683432541088Apple-tab-span" style="white-space:pre-wrap"> </span>…<br><span class="m_-259927683432541088Apple-tab-span" style="white-space:pre-wrap"> </span>}<br>}<br>private extension Coordinate {<br><span class="m_-259927683432541088Apple-tab-span" style="white-space:pre-wrap"> </span>/// Private validation of the coordinate.<br><span class="m_-259927683432541088Apple-tab-span" style="white-space:pre-wrap"> </span>func validate(latitude: Double, longitude: Double) -> Bool {<br><span class="m_-259927683432541088Apple-tab-span" style="white-space:pre-wrap"> </span><span class="m_-259927683432541088Apple-tab-span" style="white-space:pre-wrap"> </span>…<br><span class="m_-259927683432541088Apple-tab-span" style="white-space:pre-wrap"> </span>}<br>}<br>```<br><br>This is legible and intuitive. The current behaviour is not.<br><br>_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></div></blockquote></div><br></div></div>_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div><br></div></div></div></div>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>