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

David Hart david at hartbit.com
Tue Mar 15 02:40:26 CDT 2016


Oops, Shawn Ericsson already said it better than me :)

Sent from my iPhone

> On 15 Mar 2016, at 08:38, David Hart via swift-evolution <swift-evolution at swift.org> wrote:
> 
> How about:
> 
> var whatever: String {
>     private(file) set // default implementation
> }
> 
> And
> 
> var whatever: String {
>     private set {
>         return "custom"
>     }
> }
> 
>> On 15 Mar 2016, at 05:12, Russ Bishop via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>>>> On Mar 14, 2016, at 8:51 PM, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 
>>>> 
>>>> On Mar 14, 2016, at 8:36 PM, Patrick Pijnappel via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 
>>>> Another +1 for James' idea to use private(module), private(file), private:
>>>> - It avoids ambiguity whether internal/private/local is more restrictive and replaces it with a single axis, public vs. private.
>>>> - The two longer terms, private(module) and private(file), are the least used ones.
>>>> - As mentioned by Joe, it admits clean extension to groupings between file and modules in the future (e.g. submodules).
>>>> 
>>>> The only question is (as Sean mentioned) how this combines with the syntax for setter access level, e.g. the current private(set). Options:
>>>> - Unnamed 2nd argument, giving private(file), private(file, set), private(set).
>>> 
>>> We could conceivably reskin private(set) too. A lot of people complain it's "weird" as-is, for better or worse.
>>> 
>>> -Joe
>> 
>> That’s because it is weird :)
>> 
>> I always thought the computed form should be:
>> 
>> public var whatever: String {
>>     get { … }
>>     // override overall visibility to restrict setter
>>     private set { … }
>> }
>> 
>> 
>> For this proposal you could do something like:
>> 
>> var private set whatever: String = ""
>> 
>> 
>> 
>> Russ
>> _______________________________________________
>> 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/20160315/45ae5f8d/attachment.html>


More information about the swift-evolution mailing list