[swift-evolution] [Proposal] Property behaviors

Andrew Bennett cacoyi at gmail.com
Thu Dec 17 17:34:50 CST 2015

Great work Joe! I really like this.

I presume the standard library will come with the existing lazy behavior.

It would be nice to have access the sync function used by Swift 2 'lazy',
but for new behaviors. It may be that the usefulness/consistency of this is
contingent on lazy being implemented only with the standard library (maybe

My only concern is that it's not currently obvious (without the
proposal) what the type requirements of a behavior are. It feels like it
could have a protocol but probably doesn't need one as it's a language
feature. A badly conforming behavior would really need good and accurate
error messages.

It would be important that these are debugable, and that lldb prints
something sensible when you print an instance using them.

I missed it if it was mentioned, but access to a behavior (i.e. foo.
resettable.reset()) should probably be private by default, and perhaps
allow other access modifiers.

On Friday, 18 December 2015, Michel Fortin via swift-evolution <
swift-evolution at swift.org> wrote:

> Le 17 déc. 2015 à 16:36, Joe Groff <jgroff at apple.com <javascript:;>> a
> écrit :
> >> On Dec 17, 2015, at 1:14 PM, Michel Fortin <michel.fortin at michelf.ca
> <javascript:;>> wrote:
> >>
> >> About synchronized access, it seems to me that it'd be advantageous if
> implementing subscript in a behaviour was optional. This way you can force
> access of a property through a synchronized block which will help avoid
> races:
> >>
> >>      var (synchronized) data: (x: Int, y: Int, z: Int)
> >>
> >>      func test() {
> >>              data.synchronize { (data) in
> >>                      data.x += 1
> >>                      data.y += data.x
> >>                      data.z += data.y
> >>              }
> >>      }
> >
> > Interesting. IIUC, if a behavior didn't supply a subscript operation,
> then the property could *only* be accessed through its behavior interface?
> Exactly. It's much better than having a `fatalError("Don't access
> directly")` in the subscript getter.
> --
> Michel Fortin
> michel.fortin at michelf.ca <javascript:;>
> https://michelf.ca
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <javascript:;>
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151218/4116d8f9/attachment.html>

More information about the swift-evolution mailing list