> On Jun 29, 2016, at 11:06 AM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > On Wed, Jun 29, 2016 at 11:03 AM, Matthew Johnson <matt...@anandabits.com > <mailto:matt...@anandabits.com>> wrote: > >> On Jun 29, 2016, at 10:55 AM, Xiaodi Wu <xiaodi...@gmail.com >> <mailto:xiaodi...@gmail.com>> wrote: >> >> On Wed, Jun 29, 2016 at 10:52 AM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>wrote: >> >>> On Jun 29, 2016, at 10:46 AM, Sean Heber <s...@fifthace.com >>> <mailto:s...@fifthace.com>> wrote: >>> >>>> >>>> On Jun 29, 2016, at 10:22 AM, Matthew Johnson via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>> >>>> >>>>> On Jun 29, 2016, at 10:08 AM, David Hart <da...@hartbit.com >>>>> <mailto: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.
That wasn’t intentional, sorry. I misunderstood and thought you meant it would be used more frequently in code than previously thought. Thanks for clarifying. I certainly don’t oppose a better name if anyone can suggest one that is clearly better. But I am skeptical that this is possible given the amount of bike shedding that has already happened. > > >> >> >> 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 <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
