[swift-evolution] Request for Discussion: Setup closures
Erica Sadun
erica at ericasadun.com
Sun Dec 6 15:06:04 CST 2015
Do you want me to tweak that? Or remove it entirely? Also, I think I forgot to name-drop you slightly earlier as well
> On Dec 6, 2015, at 2:04 PM, David Waite <david at alkaline-solutions.com> wrote:
>
> 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 <mailto: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/f637e589/attachment.html>
More information about the swift-evolution
mailing list