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

[Biala]

In real life only public and private make sense. So it may be just private and everything else is public by default. Public may stay for compatibility :) And saying that I think there is no need to change anything as the current model is good enough.
What ever you do - don,t break existing code. Swift is not beta anymore...No one can invest in big projects if the syntax is unstable!
 

    On Thursday, March 24, 2016 2:17 PM, Goffredo Marocchi via swift-evolution <swift-evolution at swift.org> wrote:
 

 I think that supercalifragilisticexpialidocious may benefit from lowerCamelCasing ;).

[[iOS messageWithContent:webContent] broadcast]
On 24 Mar 2016, at 11:02, Dany St-Amant via swift-evolution <swift-evolution at swift.org> wrote:




Le 24 mars 2016 à 01:13, Chris Lattner via swift-evolution <swift-evolution at swift.org> a écrit :





<responding to several posts in this thread at once>





[..snip..]


How about we continue this trend, and follow other existing Swift keywords that merge two lowercase words (associatedtype, typealias, etc), and use:





    public


    moduleprivate


    fileprivate


    private





The advantages, as I see them are:


1) We keep public and private meaning the “right” and “obvious” things.


2) The declmodifiers “read” correctly.


3) The unusual ones (moduleprivate and fileprivate) don’t use the awkward parenthesized keyword approach.


4) The unusual ones would be “googable”.


5) Support for named submodules could be “dropped in” by putting the submodule name/path in parens: private(foo.bar.baz) or moduleprivate(foo.bar).  Putting an identifier in the parens is much more natural than putting keywords in parens.





What do you all think?


The think I fear with moduleprivate and fileprivate, is that someone will one day suggest to lowerCamelCase them. The parenthesized version was de-facto preventing my fear from ever being reality.
Obviously, I am on the "all keywords should be all lowercases" team.

Dany
_______________________________________________
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/20160324/b7a5b088/attachment.html>