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
> <[email protected]> wrote:
>
>
>>> 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]> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
