Two-for-Tuesday: Resettable Properties


(Jason Patterson) #1

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 <felixcca@yahoo.ca> 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 > <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:

@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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Brent Royal-Gordon) #2

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.

I think that's a slight misunderstanding of our process here. Where practicable, we usually break up large proposals into separate parts so that they can each be reviewed and implemented separately, particularly when a part of the design is underdeveloped or controversial. But that doesn't mean we've removed the feature, just that it's being designed separately.

Though the out-of-band operations feature was subsetted out of that particular proposal, that removal was only temporary. The long term plan (last time I heard) was still to include that feature in some form.

···

--
Brent Royal-Gordon
Architechies