You perfectly articulated what I've been trying to say and I agree 100% with your concerns.
While we are in a minority, I think it's important to consider how the use of private in three keywords could become confusing to people learning the language and even just in a slight mental lapse while coding: "wait what kind of private do I need?" Brandon > On Mar 25, 2016, at 12:15 PM, Jordan Rose via swift-evolution > <swift-evolution@swift.org> wrote: > > >>> On Mar 24, 2016, at 16:20 , Erica Sadun via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >>> >>>> On Mar 24, 2016, at 5:13 PM, Brent Royal-Gordon <br...@architechies.com> >>>> wrote: >>>> >>>> I think it does. `module` could mean many things related to how Swift >>>> creates and consumes modules. >>>> `moduleprivate` combines something about access levels (public/private) >>>> and scope (module), is easy to >>>> Google, offers few "wrong" interpretations. By using a longer keyword, it >>>> is less flexible in meaning and >>>> more fixed in purpose. >>> >>> Sure, but is that worth 7 to 9 extra characters at every single use site >>> for something that's actually pretty common? Is it worth the muddled mess >>> of an all-lowercase keyword with no obvious break, or the >>> attention-grabbing of a capital letter or an underscore? >>> >>> `module` and `file` are not going to be obscure corners of the language. >>> Most people will probably learn about them at the same time they learn >>> about `public` and `private`. >>> >>> (Actually, if `module` continues to be the default, you probably won't see >>> it *that* often. You *will* see `file`, but that's the one that can't be as >>> easily confused with a declaration.) >>> >>> Obviousness for new users is great, but you can take it too far. We call >>> the type `Int32`, not >>> `SignedIntegerBetweenNegative2ToThe31stPowerAnd2ToThe31stPowerMinus1`—and >>> if we did, it's not clear the longer name would really be more obvious, >>> because it would be such a pain to read. >> >> >> `moduleprivate` is the default value. I doubt it will get used much if at >> all. I don't think `fileprivate` will get used much either >> but in such cases, I think those seven extra letters are essential and >> documenting. >> >> The two remaining public and private access levels are simple and >> intuitively obvious. > > I'm going to say that I remain unhappy with these new names. I don't believe > that these won't get used, and I don't want them to feel awkward, > discouraged, or penalized when they do. The standard library, for example, > has in its style guide that all access control should be explicit, which is a > reasonable style to enforce. I also have a small concern that they won't be > easy to talk about: "this method is private" "wait, file-private or > module-private?" "neither, just private-private". > > I realize these are all vague concerns, and I don't have something more > concrete—or a better alternative. "modulescoped" and "filescoped" would be > very literally accurate but (a) would force people to learn what "scoped" > means unnecessarily, and (b) aren't less awkward. > > I agree with the concerns that just saying "file var foo" makes it sound like > there's one copy of the variable shared in the entire file, even when applied > to an instance property. I think there's a lot of value is making the access > control terms adjectives. > > I honestly still think "public, internal, private, local" is a better > taxonomy.. It's true that "internal" and "private" aren't automatically > ordered relative to each other (and maybe not even "local"), but they're all > adjectives (unlike "module" and "file"), and they're not awkward to read or > to use in conversation. But both the core team and the list disagree, mainly > because (a) it aligns 'private' more closely with other languages, and (b) if > you're not thinking about it, more restrictive is better than less. (Both of > which I agree are good ideas.) > > Jordan > _______________________________________________ > 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
