Bikeshedding!
I would suggest three things:
Make the access modifies annotations, i.e. they are spelt with an @ and use
lower-camel case (which I think was the result of a previous Swift Evolution
proposal, otherwise what ever was agreed for annotations)
Move them to the end of the declaration because they clutter the declaration at
present, e.g. struct Foo: Bar @public { … }
Names:
@public
@module
@file
@private
Cheers,
— Howard.
> On 15 Mar 2016, at 8:18 AM, Chris Lattner via swift-evolution
> <[email protected]> wrote:
>
> Per Doug’s email, the core team agrees we should make a change here, but
> would like some bikeshedding to happen on the replacement name for private.
>
> To summarize the place we’d like to end up:
>
> - “public” -> symbol visible outside the current module.
> - “internal” -> symbol visible within the current module.
> - unknown -> symbol visible within the current file.
> - “private” -> symbol visible within the current declaration (class,
> extension, etc).
>
> The rationale here is that this aligns Swift with common art seen in other
> languages, and that many people using private today don’t *want* visibility
> out of their current declaration. It also encourages “extension oriented
> programming”, at least it will when some of the other restrictions on
> extensions are lifted. We discussed dropping the third one entirely, but
> think it *is* a useful and important level of access control, and when/if we
> ever get the ability to write unit tests inside of the file that defines the
> functionality, they will be a nicer solution to @testable.
>
> The thing we need to know is what the spelling should be for the third one.
> Off hand, perhaps:
>
> fileprivate
> private(file)
> internal(file)
> fileaccessible
> etc
>
> Some other thoughts on the choice:
> - this will be a declaration modifier, so it will not “burn” a keyword.
> - if will be a uniquely Swift thing, so there is virtue in it being a
> googlable keyword.
>
> Thoughts appreciated.
>
> -Chris
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
