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. > 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
