<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br></div><div>El 5 abr 2017, a las 14:13, Michel Fortin via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> escribió:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><div><blockquote type="cite" class=""><div class="">Le 5 avr. 2017 à 0:02, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: SourceSansPro-Regular; font-size: 15px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class=""> - fileprivate should really become much more rare, which makes it more meaningful and significant where it occurs. This was the original idea and intent behind SE-0025.</div></div></div></blockquote><div><br class=""></div><div>I think this will end up being a flawed assumption, just like last time.</div><div><br class=""></div><div>Granted: there will be less need for `fileprivate` with this. Files that implement a type will not need `fileprivate` regardless of how many extensions they use to implement the type. But note that if there is only one type defined in that file (as is often the case), `private` has absolutely the same meaning as `fileprivate`.</div></div></div></blockquote><div><br></div><div><div><span style="background-color: rgba(255, 255, 255, 0);">Looking at my company's codebase that has thousands of `fileprivate` methods, with this proposal we will be able to revert all of them to `private`.</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">So yeah, it will have great impact for us, and we basically would not need to think about where to use `private` and `fileprivate` again. The important thing for us is that a `private` implementation detail is not exposed to other types.</span></div></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">So I don't think the assumption is as flawed as before, since we have much more real world data now.</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><blockquote type="cite"><div><div><div>Files that extend multiple types for the purpose of implementing a particular feature will still require `fileprivate` if those extensions want to share some implementation details. Maybe we gain something by making this explicit with a special access level, but frankly I don't really see what those gains are.</div></div></div></blockquote><div><br></div><div>While I would avoid those patterns, I understand that some people find value in them. However, I fail to understand why this proposal would harm such practices: wouldn't those extensions be written exactly as right now?</div><br><blockquote type="cite"><div><div>I actually don't fear this will actually hamper this pattern much. People will just use `fileprivate` for these "rare" cases that actually aren't that rare. It's not that big of a problem. But that would mean the assumption is flawed.</div><div><br class=""></div><div>On the other hand, if `fileprivate`effectively becomes a rarity, then it'll mean people are shying away from this pattern. In my opinion, that'd be unfortunate.</div></div></blockquote><br><div>People that uses that pattern already have to write the word `fileprivate`, and it doesn't seem that it hasn't discouraged you from using it.</div><div><br></div><div>It certainly hasn't discouraged us to use the pattern that we considered better, even if we don't agree with the current keywords.</div></body></html>