<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Resettable properties are one of the use cases for <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0030-property-behavior-decls.md" class="">property behaviors</a> There was still dissent the last time it was brought to review, so a new version is expected in the Swift 3 window.<br class=""><div class="">
<br class="Apple-interchange-newline"><span style="color: rgb(0, 0, 0); font-family: 'Lucida Grande'; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; display: inline !important; float: none;" class="">Félix</span>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">Le 15 mars 2016 à 09:49:21, Patterson, Jason via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div class="">Hi all,<br class=""><br class="">Recently I noticed how `null_resettable` Objective-C properties were<br class="">imported into Swift. To recap, a `null_resettable` property in<br class="">Objective-C indicates that the getter returns a nonnull value, while<br class="">the setter is nullable:<br class=""><br class=""><blockquote type="cite" class="">@property (nonatomic, nonnull, null_resettable) NSString *name;<br class=""><br class="">foo.name = @"Bar";<br class="">foo.name = nil; // "resets" the property<br class=""></blockquote><br class="">Currently these are imported as implicitly unwrapped optionals (var<br class="">name: String!), which is the same as if they were `null_unspecified`.<br class="">I believe this can be improved.<br class=""><br class="">I've drafted a proposal that would improve how these are imported. In<br class="">a nutshell, Swift would add an extra "reset" method to the imported<br class="">interface which would allow users to explicitly reset the property by<br class="">name. (The above example would be imported as `var name: String; func<br class="">resetName()`.) This would improve readability and allow the getter to<br class="">return a non-optional value.<br class=""><br class="">That proposal is here:<br class=""><br class=""><a href="https://github.com/patters/swift-evolution/blob/master/proposals/0000-importing-null_resettable.md" class="">https://github.com/patters/swift-evolution/blob/master/proposals/0000-importing-null_resettable.md</a><br class=""><br class="">However, I then wondered if this feature of Objective-C would be<br class="">advantageous to bring to Swift. The thought there is to allow Swift to<br class="">declare a property getter as a non-optional type, while allowing the<br class="">setter to take an optional type. While a syntactical change has more<br class="">cost to Swift, the benefit may outweigh that.<br class=""><br class="">There were a few ideas here but I ultimately settled on a new `set?`<br class="">operator. The proposal then details the usage and ramifications of<br class="">such a change. For example, the getter would continue to return `T`<br class="">while the type of `newValue` available in the setter becomes a `T?`.<br class="">There's a corresponding change to willSet clauses.<br class=""><br class="">That proposal is here:<br class=""><br class="">https://github.com/patters/swift-evolution/blob/master/proposals/0000-resettable-properties.md<br class=""><br class="">I think that both of these solve the problem in two different ways and<br class="">submit both for your discussion and consideration.<br class=""><br class="">Thanks!<br class=""><br class=""><br class="">Jason Patterson<br class="">@patters<br class="">_______________________________________________<br class="">swift-evolution mailing list<br class="">swift-evolution@swift.org<br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></div></blockquote></div><br class=""></body></html>