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@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@swift.org> wrote:
Le 24 mars 2016 à 01:13, Chris Lattner via swift-evolution
<swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
