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

[Ross O'Brien]

Haravikk: private (type) would be the subject of another proposal.

What this proposal is about is the following (all in one file):

struct Foo {
    func doThing() {
        doPrivateThing()
    }

    private func doPrivateThing() { }
}

extension Foo {
    func doOtherThing() {
        doPrivateThing()
    }

    private func doPrivateThing() { }
}

There would be two functions called doPrivateThing(). The first is private
to the struct declaration; the second to the extension. There's no conflict
between them.

What you suggest would be a proposal of its own - it would have to be,
because types can be extended outside of their original modules, which
would beg the question of whether a property could actually be a 'public
(type)' rather than a 'private (type)'.

The reason we continue to have confusion about this (I'm guilty of this
too) is because "private" has a standard meaning in many languages and a
non-standard meaning in Swift.

Chris Lattner's explained the reasoning about conjoined keywords in a few
places I think, but the posts from this thread are here:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160321/013261.html
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160321/013439.html
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160321/013463.html


On Sat, Mar 26, 2016 at 9:13 AM, Haravikk <swift-evolution at haravikk.me>
wrote:

> I can’t find a reply that seemed to cover this so I’d like to ask again,
> but why just you a parameter on private for all hidden visibility types?
> i.e-
>
> public (current meaning of public)
> private (module) (current meaning of internal)
> private (type) (new scoped visibility, could be named scoped instead but
> I prefer type personally)
> private (file) (current meaning of private)
>
> This eliminates the need for an additional keyword, and actually trims
> internal as well, plus all visibility is then either public (externally
> accessible) or private (internally accessible with some degree of
> restriction). When used without a parameter private on its own would now
> default to private (type).
>
> The ability to place a visibility restriction only upon a getter/setter
> would be handled as a parameter value, for example:
>
> private (file: set) (value can only be set within this file)
> private (type: get, file: set) (value is accessible within type,
> sub-types and extensions, but can only be set within this file)
>
> I think it’s a very neat way to do things, and I think that for most cases
> private (type), the new default for private, is sufficient for a lot of
> use-cases. More importantly it eliminates the need for new keywords,
> actually trims one (we only need two for visibility not four) and also
> eliminates the need to find good single-word keywords that make sense on
> their own, since all limited types are explicitly grouped as private which
> should make it absolutely clear.
>
> On 26 Mar 2016, at 07:14, Cheyo Ximenez via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> I agree with Ross. Swift already redefined the common access modifiers
> meanings.
> Why not use the word 'protected' to mean 'local'?
>
> public
> internal
> private
> protected // Java got it wrong. :) This is "protected" against extensions.
>
>
> On Mar 25, 2016, at 6:57 PM, Ross O'Brien via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> The specific meaning of 'public' and 'private' in programming languages
> refers to type-based symbol visibility. I'm thinking of C++, C#, Java and
> Objective C; their 'public' is Swift's 'internal'. They have no equivalent
> to Swift's 'public'. Swift has no equivalent to their 'private'.
>
> Possibly my familiarity with other languages isn't broad enough, but this
> is why I haven't understood the idea that Swift's use of 'private' is
> "right" or "obvious". You learn Swift's meanings of these terms by coding
> in Swift, you don't learn these meanings anywhere else first.
>
> To use a hopefully recognised example: an American who wants 'chips' wants
> what a Brit calls crisps; a Brit who wants chips wants what an American
> calls french fries. Which meaning of 'chips' is more intuitive? Answer: the
> one you grew up with.
>
> On Sat, Mar 26, 2016 at 1:10 AM, Brent Royal-Gordon via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> > all of these names (public, internal, private, local) have specific
>> meaning in the context of computer languages.
>>
>> Yes, `local` has a meaning, but that meaning is generally *not* that it's
>> an access level. It usually has something to do with declaring variables
>> inside a function.
>>
>> For instance, Perl uses it to back up and restore a global variable. ML
>> uses it to create a scope (roughly). Lua and Julia use it to declare
>> lexical variables which are visible in enclosed scopes, which SE-0025's new
>> access level is specifically *not* supposed to allow.
>>
>> I don't know of any language where `local` is used as an access level. If
>> you're aware of an analogous use in another language, I'd be interested to
>> see it. But the examples I've found if anything *undermine* the suggestion
>> that `local` would be a good keyword choice.
>>
>> --
>> Brent Royal-Gordon
>> Architechies
>>
>> _______________________________________________
>> 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
>
> _______________________________________________
> 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/20160326/fe610b67/attachment.html>