That is a deal breaker for me and it is a departure of of the current swift
model of localprivate aka private.
I don’t like it. The introduction of a first class scopeprivate is not worth it
if that is one of the tradeoffs.
There are other ways to hide implementation now using nested functions.
func outside() -> Int{
func insidelocalfunc() -> Int {return 2}
return insidelocalfunc()
}
> On Mar 28, 2016, at 11:16 AM, Ilya Belenkiy <[email protected]> wrote:
>
> > Would it really make sense to allow extensions in other files to access
> > fileprivate members/funcs?
>
> no, fileprivate is limited to the specific file in which it is used.
>
> On Mon, Mar 28, 2016 at 1:13 PM Cheyo Ximenez <[email protected]
> <mailto:[email protected]>> wrote:
> Let's say that we go with
> public, moduleprivate, fileprivate, scopeprivate
>
> Would it really make sense to allow extensions in other files to access
> fileprivate members/funcs? The inclusion of the word 'file' in the name
> would make it confusing that extensions have the special power to reach into
> a fileprivate from another file. This almost begs for another access like
> typeprivate (I am not proposing this).
>
> My understating is that scopeprivate came about as a way to deal with
> extensions, perhaps the author needs to look into a way to tag
> methods/members as not extendable or hidden from extensions only. The
> solution would probably be swift specific and it should probably brake out
> from the norm of other languages.
>
>
>
>
>
>
>
> On Mar 28, 2016, at 5:46 AM, Ross O'Brien via swift-evolution
> <[email protected] <mailto:[email protected]>> wrote:
>
>> Ilya said:
>> > "public", "protected", and "private" have a very well defined meaning in
>> > OOP. We shouldn't redefine them without a good reason.
>>
>> I agree. Swift has a scope-based visibility system, not a type-based
>> visibility system, but because Swift redefines the terms 'public' and
>> 'private', programmers keep getting confused about how they're used in Swift.
>>
>> Over the last few posts, since Chris Lattner proposed switching to: 'public,
>> internal, X, private', we've had several new scales proposed. (In every
>> scale in this post, there are four terms in order of decreasing visibility,
>> with the second term being the default.)
>>
>> public, external, internal, private.
>> public, internal, private, secret.
>> external, internal, public, private.
>> public, internal, private, secret.
>> public, internal, private, local.
>>
>> At this point, respectfully, I think we can dismiss the idea that labelling
>> any given level as 'public' or 'private' is right or obvious. Swift is built
>> around clarity at the point of use. 'private' is not as clear as you
>> maintain it is.
>>
>> > Swift allows extensions, so "private" in its standard form doesn't work
>> > well -- you could just define an extension and get access to anything. The
>> > scope based private seems to be the most natural extension (pun intended
>> > :–)).
>>
>> We're redefining terms from a type-based visibility scale to a scope-based
>> visibility scale. I'm not disagreeing that an extension would allow access
>> to type-visible symbols and that this might not be the programmer's
>> intention, but that 'private' has a clear meaning in OOP and repurposing
>> 'private' is not resolving any confusion.
>>
>> > I'd like to keep "private" to be completely private and not allow class
>> > injection to gain access, but this is an edge case that could be argued
>> > either way. I can definitely live with a pure scoped access for
>> > consistency and don't want to argue the edge case in a never ending
>> > discussion.
>>
>> As far as I know, it's not an edge case in Swift, it's a non-case. Swift
>> doesn't have type-based visibility. Using Swift's system, I do understand
>> that you want 'private' to refer to the least-visible level in the hierarchy.
>>
>> However, as has already been pointed out, the scope-visible level is not the
>> least-visible conceivable. There's already discussion over whether the
>> properties of inner types should be visible to their outer types. If that
>> ever made its way to a proposal, would that level become 'private'? I think
>> we can agree that another bikeshedding conversation like this would rather
>> be avoided.
>>
>> There's also the possibility of a 'submodule' level. Chris Lattner suggested
>> that the 'private(foo.bar)' syntax might be best for this, but I don't know
>> what that means - whether 'submodule' would be within the Swift hierarchy or
>> not - but it's a possibility for the future.
>>
>> I'm repeating myself, but: inclusion of the terms 'module', 'file', and
>> 'scope' in our symbols is winning out in clarity. None of those terms has
>> changed meaning in the entire discussion. The only question is exactly how
>> they should be welded to the term 'private'. There've been three suggestions
>> for doing this so far and they're all awkward, either because they have
>> parentheses or they're conjoined, but they're unambiguous in meaning and
>> no-one's suggested any single-word ideas with the same clarity.
>>
>> public, private(module), private(file) and private(scope).
>> public, moduleprivate, fileprivate, scopeprivate.
>> public, privatetomodule, privatetofile, privatetoscope.
>>
>> I'm tempted to go one further, but if you want to ignore that one further,
>> skip the next two paragraphs:
>>
>> Abandon the words 'public' and 'private'. Let's just accept that, together
>> with 'protected', these are well-defined terms of type-based visibility in
>> OOP which are orthogonal to Swift's hierarchy, and that redefining them
>> leads to confusion. Embrace 'external' and 'internal' in their places:
>>
>> external, internal(module), internal(file), internal(scope).
>> external, moduleinternal, fileinternal, scopeinternal.
>> external, internaltomodule, internaltofile, internaltoscope.
>>
>> If you ignored that, welcome back.
>>
>> I hope I've not been too antagonistic about this. I really want Swift to use
>> terms with clear meaning, and if that breaks code, I want a clean break that
>> can be easily healed / migrated.
>>
>> Every suggestion for relabelling this hierarchy, bar 'public, internal,
>> private, local/scope', breaks code.
>>
>> Adding the scope-visible level allows for greater control, but I don't
>> believe module-visible and file-visible levels would be uncommon with its
>> inclusion, so the terms for all three - all four, really - should be
>> balanced in their 'ugliness'.
>>
>> What the proposal as it stands does need to make clear is what would change
>> and what would be left behind.
>>
>> If 'internal' is renamed to 'moduleprivate', explicit uses of 'internal'
>> need to be replaced.
>>
>> If there are constants, 'global' functions, operators, or anything that can
>> be defined outside of a scope, their least visible level is fileprivate.
>> They can never be 'scope-private'.
>>
>> If 'private' is redefined, it is no nearer to its meaning in other languages
>> than it is now.
>>
>>
>> On Mon, Mar 28, 2016 at 12:30 PM, Matthew Judge via swift-evolution
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>>
>> On Mon, Mar 28, 2016 at 6:41 AM, Ilya Belenkiy <[email protected]
>> <mailto:[email protected]>> wrote:
>> lexical scope is the other way around: "inner" can see "outer". For example:
>>
>> func f() {
>> let outer = 0
>> // f cannot use inner
>> func g() {
>> let inner = 1
>> // g can use outer
>> }
>> }
>>
>>
>> Maybe I'm off in my terminology, but I think my code example matches what
>> you are saying here (outer is visible to g() but inner is not visible to f()
>>
>> It would work the same way for the access level. That said, I'd rather not
>> include this in the proposal.
>>
>> So as the proposal stands now, what is the scope that innerVar is visible to
>> in the following code: Inner or Outer?
>>
>> class Outer {
>> class Inner {
>> private var innerVar: Int
>> }
>> }
>>
>> The only change that the core team requested was the name changes. I
>> personally would prefer a completely private version where you cannot inject
>> a class into a scope to get access to the scope internals, but it's an edge
>> case that could be argued either way, and I don't want to start another
>> lengthy discussion. We already had quite a few.
>>
>> On Sun, Mar 27, 2016 at 11:17 PM Matthew Judge <[email protected]
>> <mailto:[email protected]>> wrote:
>> I know it was suggested that it be the subject of a different thread, but it
>> might be good to clarify how the new private is going to work (or at least
>> what is currently envisioned).
>>
>> My understanding is that the new private would be:
>> - visible only to the immediately enclosing scope
>> - including the scope of a inner nested scope
>> - not including the scope of an outer nested scope
>> - not visible to an extension
>>
>> Said in code (all in the same file):
>> ----------
>> class Outer { // Outer visible to module
>> private var a: Int // visible to Outer, Inner1, & Inner2
>>
>> class Inner1 { // Inner1 visible to module
>> private var b: Int // visible to Inner1 only
>> }
>> private class Inner2 { // visible to Outer & Inner(s)
>> var c: Int // visible to Outer & Inner(s)
>> }
>> }
>>
>> extension Outer { // visible to module
>> // 'a', 'b', and 'Inner2' NOT visible
>> }
>> ----------
>> If this is the intended meaning of private, then fileprivate seems to be the
>> same as private (private to the enclosing scope... which happens to be the
>> file).
>>
>> Something declared "private" at the top level of a file is fileprivate.
>> There would still need to be a way to reference scopes other than the
>> immediate one (especially since there is no way to say "private" and mean
>> moduleprivate), though I think it would strengthen the argument for
>> something along the lines of "private(file)", since it would even further
>> reduce the cases where you are spelling something more than just "private"
>>
>>
>> On Mar 27, 2016, at 17:31, Haravikk via swift-evolution
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>>>
>>>> On 27 Mar 2016, at 19:34, Jose Cheyo Jimenez via swift-evolution
>>>> <[email protected] <mailto:[email protected]>> wrote:
>>>>
>>>> Public
>>>> External (default)
>>>> Internal
>>>> Private
>>>
>>> I still feel like these are still too vague; I’m not sure I like the use of
>>> external, as public to me is external since it exports outside of the
>>> module, whereas what you’re proposing is in fact just limited to the module
>>> itself. I dislike the current internal keyword too, but at least it reads
>>> as “internal to this module", this is why the more specific terms are
>>> better like:
>>>
>>> public as-is, item is public/exported outside
>>> of module
>>> private(module) or private current internal, item is private to
>>> this module, would be the default
>>> private(file) current private, item is private to
>>> this file
>>> private(scope) new visibility type, item is private to
>>> the current scope
>>>
>>> Assuming I’m understanding the restriction properly this time =)
>>>
>>> It’s also the easiest method if we do add another visibility later for
>>> sub-classes such as private(type), as it doesn’t even require a new keyword.
>>
>>> _______________________________________________
>>
>>>
>>> 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] <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] <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
