On Wed, Jun 29, 2016 at 11:03 AM, Matthew Johnson <matt...@anandabits.com> wrote:
> > On Jun 29, 2016, at 10:55 AM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > On Wed, Jun 29, 2016 at 10:52 AM, Matthew Johnson via swift-evolution < > swift-evolution@swift.org>wrote: > >> >> On Jun 29, 2016, at 10:46 AM, Sean Heber <s...@fifthace.com> wrote: >> >> >> On Jun 29, 2016, at 10:22 AM, Matthew Johnson via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> >> On Jun 29, 2016, at 10:08 AM, David Hart <da...@hartbit.com> wrote: >> >> Sorry if I wasn’t expressing myself well enough. In my original email, I >> said that: >> >> The new rules make `private` more prominent compared to `fileprivate` >> (the latter has a somewhat worse name). >> >> >> So I agree that my issue is more with the naming than the functionality. >> I’m mainly complaining that because of its name, `fileprivate` feels like >> more of a special corner case of `private`. But in the style of writing >> types through extensions, `fileprivate` will become much more prevalent >> than `private`, which feels slightly backwards. >> >> >> I don’t view it as more of a special corner case at all, but I can see >> why you feel that way since it has an unprecedented (AFAIK) and more >> verbose name. >> >> The proposal originally left `private` alone and used a new name for the >> new access level. We weren’t able to find a name that didn’t have problems >> which led to the idea of renaming the existing `private`. >> >> My perspective is that it’s just the best name we could come up with for >> the concept in the context of the various access levels we want to >> support. The name isn’t intended to discourage use in any way. >> >> >> It may not be intended, but that doesn’t mean it won’t, though. :P >> >> I can’t say exactly *why*, but I feel similar to David here in that >> “fileprivate” is such an… odd… name that I’m inclined to just not use it >> and let things default to “internal” instead. In fact, I have *already* >> caught myself doing this. I don’t know if that’s *bad* exactly (would more >> things being internal actually aid the compiler/optimizer?), >> >> >> I’m pretty sure more things being internal will not help the optimizer. >> In fact, if you are not compiling with WMO turned on it could prevent >> optimizations. >> >> but I think this is a valid concern. The issue here is rooted in >> psychology, not technology. :/ >> >> >> That’s a fair perspective. But a *significant* amount of time was spent >> bike shedding this. I’m not sure whether you and David participated or >> not, but that was the time to have the naming discussion. >> > > I think the case being made here is that `fileprivate` was settled on when > it was thought that it would be rarely used. With what's emerged in this > discussion, it turns out that `fileprivate` might be more useful than > previously thought, and the awkwardness of the name therefore is more > troublesome than when the naming discussion first took place. > > > The example in this thread (placing data members in the type declaration > and methods in extensions) is one that received ample discussion during the > earlier threads and the review. > > I don’t know that `fileprivate` will be used in code more commonly than > previously thought. The issue is about the default access level of members > inside a `private` type (i.e. when access is *not* directly specified). > With Jordan’s proposed solution, `fileprivate` will be used to describe > these members in documentation and diagnostics. > > It will also be possible to state this default explicitly, but I don’t > think that will be too common. This is the only change in what is possible > to do *in code* from the original proposal. > You're adding words to my argument that I didn't put there. I didn't specify "in code". Awkward is awkward, in code or in documentation. > > > >> IMO the value of having more control over visibility far outweighs a >> slightly awkward name for file level visibility. I don’t think it’s >> anywhere near awkward enough to avoid, but I suppose YMMV. >> >> >> l8r >> Sean >> >> >> >> _______________________________________________ >> 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
