[swift-evolution] [Review] SE-0030 Property Behaviors

Joe Groff jgroff at apple.com
Mon Feb 15 17:13:47 CST 2016


> On Feb 15, 2016, at 3:09 PM, plx via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Feb 15, 2016, at 4:45 PM, Joe Groff <jgroff at apple.com <mailto:jgroff at apple.com>> wrote:
>> 
>> On Feb 14, 2016, at 12:02 PM, plx via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> As far as I have followed it, it does seem that it’s only `synchronized`-style behaviors that are fundamentally-problematic under composition; that is, using the terminology in the proposal, linear behavior composition would work fine, and to my eyes most behaviors are “linear”.
>> 
>> Behaviors that make synchronization promises are an obvious problem with composition, but there are also subtle issues with other compositions. Consider the composition of `lazy` with `didSet`—if you apply `didSet` inside `lazy`, you'll observe the lazy initialization as a "set" of the lazy storage, whereas you won't if you apply `lazy` inside `didSet`.
> 
> I see what you mean, but I’m curious: 
> 
> Is there some fundamental implementation challenge here (e.g. `didSet` seeing an `oldValue` that might be initialized, unexpectedly-nil, or similar…)?
> 
> Or it this more of a “there’s too much room for confusion here”-style concern?

Linear composition is easy from an implementation point of view, so my concern is definitely in the "room-for-confusion" realm, especially since the potential for confusion is in the realm of things that are easy to miss in testing, such as race conditions.

-Joe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160215/897f50a3/attachment.html>


More information about the swift-evolution mailing list