It doesn't solve the problem for me. "These properties are private." "To what?" "Just private" / "To the scope".
They're also still awkward to read in code. I know we have lots of decl modifiers, but I've convinced myself we're not in Java's "public static void main" soup situation yet. Jordan > On Mar 25, 2016, at 9:27 , Ross O'Brien <[email protected]> wrote: > > Well... how about we reverse the terms: call them 'privatetomodule' and > 'privatetofile'. > > This is 'private(module)' and 'private(file)' but fitting the all lower-case > style. It puts 'private' first (and when you use the keyword, 'private' is > the bit you want to start with more than 'module' or 'file'). It's easier to > use in conversation ("these properties are private to the file"). > Disadvantage: it adds 'to', so the words are even longer (but no longer than > the parenthesised form would've taken). > > 'privatetofile extension Foo : BarConvertible { }' > > On Fri, Mar 25, 2016 at 4:15 PM, Jordan Rose via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > >> On Mar 24, 2016, at 16:20 , Erica Sadun via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >>> >>> On Mar 24, 2016, at 5:13 PM, Brent Royal-Gordon <[email protected] >>> <mailto:[email protected]>> 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 > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
