> 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
