On Wed, 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'm not sure if this is something we want to reopen, though, or what the > right process would be. > Right. I agree with your criteria and your doubts about how to reopen the topic. I'd offer that what's definitely not the right process is continuing in this thread :) > > Austin > > On Wed, Jun 29, 2016 at 9:10 AM, Matthew Johnson via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> 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 >> > 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. >> >> >> 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 >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> >>> >> >> >> _______________________________________________ >> 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