Recently I noticed how `null_resettable` Objective-C properties were
imported into Swift. To recap, a `null_resettable` property in
Objective-C indicates that the getter returns a nonnull value, while
the setter is nullable:
foo.name = @"Bar";
foo.name = nil; // "resets" the property
Currently these are imported as implicitly unwrapped optionals (var
name: String!), which is the same as if they were `null_unspecified`.
I believe this can be improved.
I've drafted a proposal that would improve how these are imported. In
a nutshell, Swift would add an extra "reset" method to the imported
interface which would allow users to explicitly reset the property by
name. (The above example would be imported as `var name: String; func
resetName()`.) This would improve readability and allow the getter to
return a non-optional value.
That proposal is here:
However, I then wondered if this feature of Objective-C would be
advantageous to bring to Swift. The thought there is to allow Swift to
declare a property getter as a non-optional type, while allowing the
setter to take an optional type. While a syntactical change has more
cost to Swift, the benefit may outweigh that.
There were a few ideas here but I ultimately settled on a new `set?`
operator. The proposal then details the usage and ramifications of
such a change. For example, the getter would continue to return `T`
while the type of `newValue` available in the setter becomes a `T?`.
There's a corresponding change to willSet clauses.
That proposal is here:
I think that both of these solve the problem in two different ways and
submit both for your discussion and consideration.
Le 15 mars 2016 à 09:49:21, Patterson, Jason via swift-evolution <swift-evolution@swift.org> a écrit :
Hi all,
Recently I noticed how `null_resettable` Objective-C properties were
imported into Swift. To recap, a `null_resettable` property in
Objective-C indicates that the getter returns a nonnull value, while
the setter is nullable:
foo.name = @"Bar";
foo.name = nil; // "resets" the property
Currently these are imported as implicitly unwrapped optionals (var
name: String!), which is the same as if they were `null_unspecified`.
I believe this can be improved.
I've drafted a proposal that would improve how these are imported. In
a nutshell, Swift would add an extra "reset" method to the imported
interface which would allow users to explicitly reset the property by
name. (The above example would be imported as `var name: String; func
resetName()`.) This would improve readability and allow the getter to
return a non-optional value.
However, I then wondered if this feature of Objective-C would be
advantageous to bring to Swift. The thought there is to allow Swift to
declare a property getter as a non-optional type, while allowing the
setter to take an optional type. While a syntactical change has more
cost to Swift, the benefit may outweigh that.
There were a few ideas here but I ultimately settled on a new `set?`
operator. The proposal then details the usage and ramifications of
such a change. For example, the getter would continue to return `T`
while the type of `newValue` available in the setter becomes a `T?`.
There's a corresponding change to willSet clauses.
That proposal is well-written and the syntax is simple to understand.
I think I like this better than the out-of-band `reset` proposed as part of property behaviors. I've never been a fan of those out of band functions.
···
Le 15 mars 2016 à 9:49, Patterson, Jason via swift-evolution <swift-evolution@swift.org> a écrit :
There were a few ideas here but I ultimately settled on a new `set?`
operator. The proposal then details the usage and ramifications of
such a change. For example, the getter would continue to return `T`
while the type of `newValue` available in the setter becomes a `T?`.
There's a corresponding change to willSet clauses.