[swift-evolution] Proposal: Bitmask-style syntax for Method Chaining

[Chuquimia, Max]

Greetings, fellow Swiftlets!

I am very interested to hear what you guys think about method chaining in a
similar style to Swift’s bitmask handling.
Yes, there’s a healthy discussion on “Setup Closures”, but let’s
dispatch_async to start a new (albeit parallel) thread regarding a neat way
to access properties.
No doubt you’ve found yourself writing something similar to the following:

someViewController.view.layer.shadowColor = UIColor.grayColor().CGColor
someViewController.view.layer.shadowRadius = 5.0
someViewController.view.layer.shadowOffset = CGSizeMake(0.0, 0.5)
someViewController.view.layer.shadowOpacity = 0.75

It can be disturbing to see someViewController.view.layer repeated so many
times, however we are currently unable to refactor these lines without
subclassing and possibly affecting other areas of implementation.

What I propose is a natural way of assigning properties on layer with a
syntax we are all already used to:

someViewController.view.layer = [
    .shadowColor = UIColor.grayColor().CGColor,
    .shadowRadius = 5.0,
    .shadowOffset = CGSizeMake(0.0, 0.5),
    .shadowOpacity = 0.75
]

Which is of course similar to our belovèd
someViewController.view.autoresizingMask
= [.FlexibleWidth, .FlexibleHeight]

Of course, this is an extreme example of keypath length, however I believe
this language feature would still be beneficial for shorter keypaths (think
accessing self within closures or the recent proposal to reinstate self.)

Using [] instead of {} eliminates the risk of ambiguity if a method
such as func
layer(c: Void -> Void) has been defined in the view’s class. Apart from
that, I can’t think of any possible conflicts, and as it’s an addition
there will be no migration required when moving to a new language version

Interested in your thoughts,

MaxC
​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151216/b92c1f4b/attachment.html>