[swift-evolution] Two-for-Tuesday: Resettable Properties
Brent Royal-Gordon
brent at architechies.com
Wed Mar 16 22:28:04 CDT 2016
> 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
More information about the swift-evolution
mailing list