> 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
