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