[swift-evolution] access control proposal

[David Owens II]

I tend to disagree with this whole concept of access modifiers; what we have today is at least somewhat sane and consistent across all constructs.

As for your example, if other code within your file is leveraging these “private” pieces, doesn’t that suggest that your API model is already wrong? After all, those pieces wouldn’t be used if they weren’t needed. I’m also hard pressed to believe that this is solving a problem that isn’t purely academic.

I’d actually prefer the opposite extreme: I want everything public unless it’s prefixed with an _. To me, the _ prefix adds significantly more contextual awareness that I’m venturing into parts of the construct that are not intended for general use. It has the add benefit that it makes these types of uses grepable within the codebase so audits are quite trivial.

    struct F {
        func _privateUsage() {}
        func publicUsage() {}
    }

Right now, I find having to prefix nearly everything with public is extremely annoying.

Humorously enough, I’m actually running into issues with this right now. I’m looking into fixing some of the NSNumber functionality in corelib and the fact that some of the internal state is marked as private means it’s not readably testable nor easy to inspect to validate is doing the right thing.

-David

> On Dec 5, 2015, at 9:04 PM, Nikolai Vazquez via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I agree that there should be an access level that hides implementation details from other types in the same file. However, it shouldn’t replace private, because 1) helper types might benefit from private elements and 2) like you said, backwards compatibility.
> 
> On Sat, Dec 5, 2015 at 11:40 PM Ilya via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
> 
> 
> I think the it would help a great deal to have an access level modifier that is really private and visible only inside the class itself. Right now, the only way to hide implementation details for a class is to hide the class code in a separate file, which is very inconvenient for several reasons:
> 
> 1) the meaning of the code changes depending on which file the class is in. It's very easy to accidentally expose class internal details and then call class elements that are meant to be used only inside the class. Having a keyword for class internals will allow the compiler to ensure that only the public API for the class is used from the outside world. The user can check types on his own, but it's better that the compiler does it automatically. Similarly, the user can check that only the proper APIs are called, but it's better that the compiler does it automatically.
> 
> 2) accessibility by file structure may cause some really short files. 
> 
> 3) It's impossible to group related classes in one file but still hide implementation details inside each class
> 
> I think that it the best solution is to make private keyword do what it states -- keep the class element private to the class. But if it's really important to have a separate keyword for backward compatibility, it would be the next best thing.
> 
> --
> Ilya Belenkiy
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <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/20151205/57430d82/attachment.html>