[swift-evolution] Request for Discussion: Setup closures

[Matthew Johnson]

Thanks Erica. I agree that there are two distinct, but related problems being discussed here as well as several ideas for solutions.  

I will try to provide a side-by-side summary of the problems and proposed solutions in the next day or so when I have a chance to pull it together.


> On Dec 6, 2015, at 11:26 AM, Erica Sadun <erica at ericasadun.com> wrote:
> 
> Matthew, I'll look for it and see what's there. More and more I'm thinking there are in fact two distinct problems to be solved: one that maintains self in a cascade of operations, and another that extends initializers, even for constants.
> 
> I'm hesitant to coalesce and summarize all this discussion yet because I'm already committed to championing the for-loop proposal but it seems that it would be really valuable right now to lay out the two side-by-side and discuss that plus your helpers-for-initializing-peroperties-of-same-name-as-parameters.
> 
> -- E
> p.s. In my head, I'm thinking that the compiler must check in setup closures or self-specific-closures for potential overlaps between properties and existing symbols
> 
> 
>> On Dec 6, 2015, at 10:22 AM, Matthew Johnson <matthew at anandabits.com <mailto:matthew at anandabits.com>> wrote:
>> 
>> Hi Erica,
>> 
>> You might be interested in a possible language feature I described in the "helpers for initializing properties of same name as parameters" thread last night.  It is intended to address the desire for concise, safe and flexible initialization without needing to sacrifice immutability.   I would love to hear your thoughts on the list if you have a chance to read through it.
>> 
>> Thanks,
>> Matthew
>> 
>> Sent from my iPad
>> 
>> On Dec 6, 2015, at 11:10 AM, Erica Sadun via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> I have developed something similar as well (http://ericasadun.com/2015/11/15/speeding-up-swift-playgrounds-with-closure-initialization-swiftlang/ <http://ericasadun.com/2015/11/15/speeding-up-swift-playgrounds-with-closure-initialization-swiftlang/>).
>>> 
>>> Is yours capable of handling enums and structs that would otherwise be let after declaration because mine is not.
>>> 
>>> -- E
>>> 
>>> 
>>>> On Dec 5, 2015, at 5: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/00f42000/attachment.html>