On Tue, Mar 15, 2016 at 2:33 PM Erica Sadun <erica at ericasadun.com
<https://lists.swift.org/mailman/listinfo/swift-evolution>> wrote:
> And again, moving the access control modification to the end just doesn't
> look
> right to me or seem to enhance readability. :(
I like Shawn’s proposal better for cases where there are custom getter/setter
implementations. We should definitely be able to do:
var foo:Int {
public get {…}
private(file) set {…}
}
In fact, that is what I first tried to do before learning about private(set).
But without the implementations, it just seems strange to put the scoping after
the rest of the declaration (they work above because they are before the custom
getter/setter).
I still like the idea of having the option to use parameter-like syntax for
cases where you don’t have custom getters/setters:
private var foo:Int
private(file) var foo:Int
private(set: file) var foo:Int
private(get: global, set: file) var foo:Int
I guess, if we had some way to represent the standard getter/setter, that might
work too. I don’t love it, but maybe with better wording?
var foo:Int{
public get useDefault
private(file) set {…}
}
Thanks,
Jon
> On Mar 14, 2016, at 10:22 PM, Patrick Pijnappel <[email protected]>
> wrote:
>
> I like Shawn's proposal:
>
> var foo: Int { private(file) set }
>
> In fact it's probably more sensible than the current private(set) IMO.
>
> For example, we already use
>
> var foo: Int { mutating get { ... } }
>
> and not
>
> mutating(get) var foo: Int { get { ... } }
>
> On Tue, Mar 15, 2016 at 4:13 PM, Patrick Pijnappel
> <[email protected] <mailto:[email protected]>> wrote:
> 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
> <[email protected] <mailto:[email protected]>> 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
> [email protected] <mailto:[email protected]>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>
>
>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
