[swift-evolution] Request for Discussion: Setup closures

[Vinicius Vendramini]

While I understand the motivation behind this change, I think it’s pretty far from paying the addition of a new language feature. Is this

let questionLabel = UILabel() {
    $0.textAlignment = .Center
    $0.font =  UIFont(name:"DnealianManuscript", size: 72)
    $0.text = currentQuestion.questionText
    $0.numberOfLines = 0
    view.addSubview($0)
}

really that much better than this?

let label = UILabel()

label.textAlignment = .Center
label.font =  UIFont(name:"DnealianManuscript", size: 72)
label.text = currentQuestion.questionText
label.numberOfLines = 0
view.addSubview(label)

To be honest, the second looks much more readable to me. I like the indentation of the first one, but that doesn’t sound like enough of a reason: one could easily re-indent the lines to one’s liking (which actually looks kinda good with 4-spaces indentation, since `var` or `let` plus a space equals 4 characters:)

let label = UILabel()
    label.textAlignment = .Center
    label.font =  UIFont(name:"DnealianManuscript", size: 72)
    label.text = currentQuestion.questionText
    label.numberOfLines = 0
    view.addSubview(label)

As far as I understand the proposals so far, this approach only changes the way we’d write the initialization, but doesn’t actually allow us to do something that couldn’t be done earlier (e.g. access internal members, change immutable variables…) right? 


> On Dec 5, 2015, at 11:31 PM, Matthew Johnson via swift-evolution <swift-evolution at swift.org> wrote:
> 
> As stated previously, I think a more specific solution is the best way to address the initialization / setup / configuration problem. While that is the case I did think some more about the ideas in this thread.
> 
> I believe two things are being proposed here:
> 
> 1. The ability to append a trailing closure to any initializer (that doesn’t already declare one itself) that accepts a single argument of the initialized type.  If the caller supplies such a closure, the compiler performs a code transformation as follows:
> 
> let questionLabel = UILabel() {
> 	$0.textAlignment = .Center
> 	$0.font =  UIFont(name:"DnealianManuscript", size: 72)
> 	$0.numberOfLines = 0
> }
> 
> becomes something like this (which is valid Swift today:
> 
> let questionLabel = UILabel(); {
> 	$0.textAlignment = .Center
> 	$0.font =  UIFont(name:"DnealianManuscript", size: 72)
> 	$0.numberOfLines = 0
> }(questionLabel)
> 
> The code transformation doesn’t actually buy us much.  I’m a big believer in removing the need for clutter and boilerplate as much as possible, but even I must admit that the difference is really small and can be reduced a bit further using currently valid Swift code as demonstrated by the “configuration operator” mentioned in the previous post.
> 
> 2. A new abbreviation of the $0 shorthand that would be valid only as the first characters on a line of code.  For consistency this shorthand should work in any closure, not just in “setup closures”.  I agree that $0 is uglier than necessary in this use case which would be relatively common in Cocoa code if this pattern becomes common.
> 
> The biggest drawback I can think of to a feature like this is that it is a feature specifically designed to make the use of var members more convenient.  It might be a good thing that “setup closures" are a little bit ugly given that they are only able to “setup" mutable members and require those members to be initialized to potentially meaningless default values (or worse, IUO members defaulted to nil!).  
> 
> Ideally an instance would be configured correctly when the initializer completes and we should work to find language solutions to make this safe and convenient.  Once we have the right language solutions ideally we can use them in new types and retrofit existing types to use them over time, thus eliminating the need for “setup closures” alltogether.
> 
> 
>> On Dec 5, 2015, at 6:16 PM, ilya via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> > PROBLEM: With many Apple-supplied classes, typical initializers fail to fully set up an instance for use.  Here's one example: ...
>> 
>> FWIW, I created a configuration operator more then a year ago, and use it in all of my Swift projects:
>> 
>> let task = NSTask() +=+ {
>>     $0.launchPath = "/usr/bin/mdfind"
>>     $0.arguments = ["kMDItemDisplayName == *.playground"]
>>     $0.standardOutput = pipe
>> }
>> 
>> Note you can also use the configured object in the rhs:
>> 
>> let questionLabel = UILabel() +=+ {
>>     $0.textAlignment = .Center
>>     $0.font =  UIFont(name:"DnealianManuscript", size: 72)
>>     $0.text = currentQuestion.questionText
>>     $0.numberOfLines = 0
>>     view.addSubview($0)
>> }
>> 
>> This $0. certainly looks ugly and it would be great to be able to simplify this. I don't llike the following much though (dot-syntax can be ambiguos here, and using simply a method name is even worse):
>> 
>> let questionLabel = UILabel() +=+ {
>>     .textAlignment = .Center
>>     .font =  UIFont(name:"DnealianManuscript", size: 72)
>>     .text = currentQuestion.questionText
>>     .numberOfLines = 0
>>     view.addSubview($0)
>> }
>> 
>> Actually I would be happy with something like
>> 
>> let questionLabel = UILabel() .{
>>     ..textAlignment = .Center
>>     ..font = UIFont(name:"DnealianManuscript", size: 72)
>>     ..text = currentQuestion.questionText
>>     ..numberOfLines = 0
>>     view.addSubview($0)
>> }
>> 
>> Other thoughts?
>> 
>>   
>>  _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
>  _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151206/7966251b/attachment.html>