I like Shawn's proposal:
var foo: Int { private(file) set }
In fact it's probably more sensible than the current private(set) IMO.
While I like private(get: file, set: module) idea, I think it just gets too
inconsistent with private(set: public) and private(set: private) (?!)
On Tue, Mar 15, 2016 at 3:39 PM, Jonathan Hull via swift-evolution <
swift-evolution@swift.org> wrote:
> *On Mar 14, 2016, at 8:36 PM, Patrick Pijnappel via swift-evolution
> <swift-evolution at swift.org
> <https://lists.swift.org/mailman/listinfo/swift-evolution>> wrote:*
>
> 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).
> - Named 2nd argument, giving e.g. private(file), private(file, accessor:
> set), private(accessor: set). Less ambiguity but longer.
> - Not using multiple arguments, but that'd probably break consistency with
> the other unification efforts going on to make everything look like
> function calls.
>
> What about the following 3 forms?
>
> private(file) //both setter and getter have file scope
> private(set: file) //setter has file scope. Equivalent to current
> “private(set)"
> private(get: module, set: file) //getter has module scope & setter has
> file scope
>
> It is a bit weird, but we should probably also allow “public" in that last
> form: private(get: public, set: module)
>
> Thanks,
> Jon
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
