[swift-evolution] Request for Discussion: Setup closures

[David Waite]

I’m leaning away from “self in” style syntax - I think there are too many cases where you still want to be able to bind and access the self of the object your closure was declared within.

I’m not sure you have to establish a new “self” however - have the type of object given to with is known, so the methods/functions available to it can be exposed as lexical scope. 

To keep code clarity, use of methods/functions which shadow something in higher lexical scope should likely result in compiler errors.

-DW

> On Dec 6, 2015, at 1:48 PM, ilya via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I applaud honest description of drawbacks in the proposal :) 
> 
> There examples given, I think, demonstrate that using self without any special access leads to unresolvable ambiguities. 
> 
> If one wants to work "inside" the configured object, this seems like a good job for a private initializer. All of the ambiguities will be resolved, because extracting the init away removes its ability to capture names from the local context. 
> 
> Alternatively, I think it makes sense to continue working on configuration syntax, with "default" access to local context and "explicit" access to the object. Let's just replace $0 with something else. 
> 
> Hopefully I don't sounds too pessimistic. Erica's proposal looks going in the right direction to me. 
> On Sun, Dec 6, 2015 at 23:30 Erica Sadun via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> It's probably better at this point for me to collect my thoughts and summarize where I am at.
> 
> https://gist.github.com/erica/eb32feb22ba99629285a <https://gist.github.com/erica/eb32feb22ba99629285a>
> 
> Please feel free to comment on-list about this proposal (github does not forward comment alerts) and
> then I will start a new list thread as a Proposal rather than as a Request for Discussion.
> 
> Best,
> 
> -- E
> 
> 
>> On Dec 6, 2015, at 12:45 PM, ilya <ilya.nikokoshev at gmail.com <mailto:ilya.nikokoshev at gmail.com>> wrote:
>> 
>> Sorry, did I misunderstand the question? 
>> 
>> Did you asked whether my definition will work for immutable value types? 
>> If that's the question, the answer is still yes, the link has an example :) 
>> 
>> On Sun, Dec 6, 2015 at 10:43 PM, Erica Sadun <erica at ericasadun.com <mailto:erica at ericasadun.com>> wrote:
>> I was specifically referring to value types. I apologize for not being clearer.
>> 
>> -- E
>> 
>> 
>>> On Dec 6, 2015, at 12:42 PM, ilya <ilya.nikokoshev at gmail.com <mailto:ilya.nikokoshev at gmail.com>> wrote:
>>> 
>>> Yes, it works for immutable objects with the correct definition, see the playground contents at https://github.com/ilyannn/iOS-Swift-Materials/blob/master/Playgrounds/Configure.playground/Contents.swift <https://github.com/ilyannn/iOS-Swift-Materials/blob/master/Playgrounds/Configure.playground/Contents.swift>
>>> 
>>> On Sun, Dec 6, 2015 at 8:10 PM, Erica Sadun <erica at ericasadun.com <mailto:erica at ericasadun.com>> 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>
>  _______________________________________________
> 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/b724b01a/attachment.html>