> On Jun 29, 2016, at 11:14 AM, Austin Zheng <austinzh...@gmail.com> wrote: > > I just want a name that is: > > - a single English language word > - whose common meaning has something to do with privacy, access, permissions, > or a similar grouping concept that the other three keywords fits into > - and intuitively describes the intensity of the behavior relative to the > other three keywords
I think everyone would like that. But nobody has been able to come up with a word that doesn’t have problems of one kind or another (for the new access level or for the file access level). > > I'm not sure if this is something we want to reopen, though, or what the > right process would be. This has received a vast amount of bike shedding already. I would like to see us continue with the implementation of SE-0025. If anyone thinks they have found a way to improve the naming a new proposal can be put forward. If an obviously better name is suggested I will support such a proposal enthusiastically! > > Austin > > On Wed, Jun 29, 2016 at 9:10 AM, Matthew Johnson via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> On Jun 29, 2016, at 11:06 AM, Xiaodi Wu <xiaodi...@gmail.com >> <mailto: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 <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
