Indeed. I actually mention that in my proposal draft. The core problem that I believe should be addressed is the mechanism that the Swift importer applies to `null_resettable` Objective-C properties. Whether or not Swift should support the feature is separate, but related, which is why I drafted two proposals.
SE-0030 initially included "out-of-band operations" (such as reset methods with syntax like `foo.name.[resettable].reset()`) but ultimately removed them due to complexities involved: > It is useful to add out-of-band operations to a property that aren't normal > members of its formal type, for instance, to cleara lazy property to be > recomputed later, or to reset a property to an implementation-defined default > value. This is useful, but it complicates the design of the feature. I agree that the use case of resettable properties is somewhat orthogonal to the goals of Property Behaviors (which, from what I understand, was originated to subsume lazy, atomicity, mutable-until-frozen, and other "member access" concerns into the standard library) since it by nature requires an operation to reset it. In other words, I feel these proposals are independent of re-review of Property Behaviors. The two proposals are to generate discussion on whether: 1. Is it a problem the way that `null_resettable` properties are currently imported? 2. Are resettable properties a useful feature to bring to Swift? Thanks, -Jason On Tue, Mar 15, 2016 at 12:01 PM, Félix Cloutier <[email protected]> wrote: > Resettable properties are one of the use cases for property behaviors There > was still dissent the last time it was brought to review, so a new version > is expected in the Swift 3 window. > > Félix > > Le 15 mars 2016 à 09:49:21, Patterson, Jason via swift-evolution > <[email protected]> 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: > > @property (nonatomic, nonnull, null_resettable) NSString *name; > > 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: > > https://github.com/patters/swift-evolution/blob/master/proposals/0000-importing-null_resettable.md > > 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: > > https://github.com/patters/swift-evolution/blob/master/proposals/0000-resettable-properties.md > > I think that both of these solve the problem in two different ways and > submit both for your discussion and consideration. > > Thanks! > > > Jason Patterson > @patters > _______________________________________________ > 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
