In terms of alternatives to fileprivate, I just want to chime in to say that "filewide" seems to be a term that people seem to reach for in describing this scope, based on a quick Google search.<br><br>It's readable, IMO, and definitely an adjective, it breaks no new ground in terms of coining a new term, and it is adequately descriptive. Plus, it avoids the issue of having two things named fileprivate and [bona fide] private.<br><br>For those reasons, it's got my vote over "file", "fileprivate", "infile", "intrafile", etc.<br><br><div class="gmail_quote"><div dir="ltr">On Fri, Apr 1, 2016 at 11:11 AM Paul Ossenbruggen via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<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"><div>How about: </div><div><br></div><div>notprivateatall</div><div>notveryprivate</div><div>mostlyprivate</div><div>stayout!!!private</div><div><br></div><div>Sorry. April fools.. :-) </div></div><div style="word-wrap:break-word"><div><br></div><div><div><blockquote type="cite"><div>On Apr 1, 2016, at 8:00 AM, Ross O'Brien via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br><div><div dir="ltr">"or within my whole program (external)". That caused a double-take on its own.<div><br></div><div>external things are not within, they are outside. 'external' could be a replacement term for 'public', not for 'internal'.</div><div><br></div><div>This may well be a subjective thing, but I don't think in files, I think in modules because that's been the default for several years now. If I create a new type I am implicitly making it visible to everywhere within this module; it is not outside the module so it is not external. I may then choose to make it less visible, but it does not 'go inside' when I do this.</div><div><br></div><div>If you think in files, I cannot say you are wrong, because it is subjective. But this is why I have been arguing for non-subjective keywords. I cannot make 'fileprivate' pretty for you but I do know that when we both read it we both understand what it means. That's why it hasn't gone away: it satisfies the criterion of clarity.</div><div><div><div><div><div><div><div><div><div><div><br></div></div></div></div></div></div></div></div></div></div><div>Find a pretty alternative with the word 'file' baked into it and I'm with you.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 1, 2016 at 3:31 PM, Sean Heber <span dir="ltr"><<a href="mailto:sean@fifthace.com" target="_blank">sean@fifthace.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A new type is implicitly visible *outside* of the file it is defined in and hence it is “external” from that point of view. This arrangement seems more “human” to me. Someone just learning isn’t going to know about modules or how the compiler is treating things anyway and they would almost never run into “external” because it’s the default and there’s no reason to specify it most of the time. IMO, this “fits” how I think about source code while I’m writing it - where do I want to be able to use this symbol? Either hidden away and safe (private), inside this file I’m working with (internal), or within my whole program (external).<br>
<br>
l8r<br>
<span><font color="#888888">Sean<br>
</font></span><div><div><br>
<br>
> On Apr 1, 2016, at 9:20 AM, Ross O'Brien <<a href="mailto:narrativium%2Bswift@gmail.com" target="_blank">narrativium+swift@gmail.com</a>> wrote:<br>
><br>
> A new type is implicitly internal to a module. Implicitly specifying it as 'external' is just plain confusing.<br>
><br>
> On Fri, Apr 1, 2016 at 3:01 PM, Sean Heber via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
> I know this is kind of winding down, and there seems to be a kind of begrudging acceptance of “fileprivate” emerging (perhaps due to fatigue), but I still really don’t like it so I’m going to toss out my current favorite configuration and try to stop caring and defer to the core team to make an executive decision so we can all move on with our lives. :P<br>
><br>
> public - unchanged, visible “everywhere"<br>
> external - visible outside of the file (module, the default)<br>
> internal - visible only within the file<br>
> private - visible only within the scope<br>
><br>
> I really like the existing private and I use it a lot to build collections of small classes and structs that work together rather than a large class/struct that tries to “be everything”. In those scenarios, traditional OO private would be too restrictive and even a “protected” access type wouldn’t work because I’m trying to avoid building inheritance hierarchies. I really need something like “friend” (ugly) or the, imo, much more elegant file-scoped access and if that one is renamed “fileprivate” I’ll be really sad seeing such an ugly label all over the place. I’d go so far as to suggest that an ugly name for this access level would actively discourage its use and while some might have that as a goal, to me that would encourage the creation of larger “do everything” classes instead of clusters of smaller classes and structs and protocols.<br>
><br>
> l8r<br>
> Sean<br>
><br>
> > On Apr 1, 2016, at 7:17 AM, Joanna Carter via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
> ><br>
> >> I’ve seen a number of concerns on this list about moduleprivate, and how it penalizes folks who want to explicitly write their access control. I’ve come to think that there is yes-another possible path forward here (which I haven’t seen mentioned so far):<br>
> >><br>
> >> public<br>
> >> internal<br>
> >> fileprivate<br>
> >> private<br>
> >><br>
> >> The advantages, as I see them are:<br>
> >> 1) We keep public and private meaning the “right” and “obvious” things.<br>
> >> 2) The declmodifiers “read” correctly.<br>
> >> 3) Compared to Swift 2, there is almost no change. The only thing that changes is that some uses of Swift 2 “private” will be migrated to “fileprivate”, which makes the intent of the code much more clear.<br>
> >> 4) fileprivate is the unusual and not-really-precedented-in-other-languages modifier, and it would still be “googable”.<br>
> >> 5) The addresses the “excessively long” declmodifier problem that several people are concerned with.<br>
> >> 6) Support for named submodules could be “dropped in” by parameterizing “internal”.<br>
> >><br>
> >> Thoughts?<br>
> ><br>
> > +1<br>
> ><br>
> > Following on from my experience with Delphi adding "strict private" for "OO private" members of classes, I would totally agree with your proposition.<br>
> ><br>
> > Having to use Delphi's "strict private" never really felt right to those of us who were brought up on the OO concept of private, and having "private" mean file scope simply encouraged very bad, large, files with lots of classes; especially for those who were new to programming.<br>
> ><br>
> > This proposal means that folks coming from other OO languages will instantly understand "private"; "fileprivate" does what it says on the tin.<br>
> ><br>
> > To my mind, the only extra scope that might be useful is the OO concept of "protected" on a class, but I would like to see a discussion purely centred on the effect of more protocols and less class inheritance, with its attendant impact on whether protected could also suit extending (otherwise private) scope to extensions.<br>
> ><br>
> > In recent experiments of adapting the GOF Design Patterns to Swift, I have found using protocols and extensions to greatly reduce the need for class inheritance, if not removing the need for classes at all in favour of structs.<br>
> ><br>
> > Joanna<br>
> ><br>
> > --<br>
> > Joanna Carter<br>
> > Carter Consulting<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" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><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" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
><br>
<br>
</div></div></blockquote></div><br></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>_______________________________________________<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>