> On Mar 14, 2016, at 8:51 PM, Joe Groff via swift-evolution
> <[email protected]> wrote:
>
>>
>> On Mar 14, 2016, at 8:36 PM, Patrick Pijnappel via swift-evolution
>> <[email protected] <mailto:[email protected]>> 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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
