[swift-evolution] SE-0025: Scoped Access Level, next steps

[Xiaodi Wu]

I disagree strongly. We might not be able to get everyone happy with the
names, but we can get to a point of good compromise, and "moduleprivate"
does not seem to me a good compromise at all.

Aesthetically, "moduleprivate" leaves much to be desired, but others have
already touched on that. I very much agree with the objection that having
"moduleprivate" and "private" makes the meaning of "private" less clear.
When we modify one word with another, we generally expect the modifying
word to restrict the universe of things denoted by the base word. For
example, top secret is more restricted than secret. Red cars are a subset
of all cars. When this expectation is violated, it's often spoken of as a
surprising thing or an unfortunate name. English horns aren't horns! red
pandas aren't pandas! moduleprivate isn't private!

On Tue, Mar 29, 2016 at 9:04 AM Ilya Belenkiy via swift-evolution <
swift-evolution at swift.org> wrote:

> -1, "external" can be also understood as "exported" or public. I think
> that the names in the updated proposal are the clearest. Also, I think that
> at this point we need to stop trying to come up with more names. I don't
> think that we will ever reach a point where everybody is happy with the
> names. The ones that we have now seems to be a good compromise that is in
> line with other Swift keywords.
> On Tue, Mar 29, 2016 at 9:23 AM Paul Ossenbruggen via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>>
>> On Mar 29, 2016, at 12:32 AM, Andrey Tarantsov via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> public (unchanged)
>> external (module access)
>> internal (file access)
>> private (scoped access)
>>
>>
>> This seems logical and something I could live with, but how is it better
>> than moduleprivate and fileprivate? Also, internal has contradictory prior
>> art in C# and Swift 2 (not that it stops us).
>>
>> And I see the length of moduleprivate and fileprivate as a feature, and
>> external/internal lacks it.
>>
>>
>> It is better than moduleprivate and fileprivate in that it is a single
>> word which is easier to to read and there is less typing. Less typing even
>> with autocomplete is a benefit. Once you know its meaning, that both are
>> relative to file access, you won’t have to look it up. Also, just noticed
>> this, when I type multiword keywords in an email program or chat program
>> autocorrect butts in. This is of practical value because much work is done
>> in chat and email programs.
>>
>> Simpler is better if it sufficiently conveys the meaning and it does in
>> this case. The expectation with most keywords are that they be single
>> words, especially ones that are used the most.
>>
>> There is a nice symmetry to internal/external and public/private.
>>
>> If external/internal refer to the file, then we don’t need the multiword
>> descriptive versions.  Also, if we decide later that scoping to namespaces
>> is desired these same already reserved keywords give us more flexibility
>> than the more specific keywords would allow. Internal/external could refer
>> to the namespace scope rather than the file scope if it is inside a
>> namespace (this is beyond the scope of the proposal but trying to think
>> ahead). By not explicitly stating the scope you gain flexibility
>>
>> - Paul
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160329/a5f34dd4/attachment.html>