[swift-evolution] Request for Discussion: Setup closures

Sun Dec 6 15:13:58 CST 2015

It seems like setting properties just after init is the main use case here.

I'm not against this idea, but I want to point out that this doesn't *need*
to be solved by a change to the language. You can easily define a convenience
init for UILabel that takes textAlignment, font, text, and numberOfLines as
parameters. They could have default values so you can specify just the ones
you need.

I like the idea of being able to do configure objects/values conveniently,
but I'm not sure how to justify a language change for it. Perhaps we just
need better autogeneration of initializers during Obj-C header import.

Jacob Bandes-Storch

On Sun, Dec 6, 2015 at 1:06 PM, Erica Sadun via swift-evolution <
swift-evolution at swift.org> wrote:

> 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> 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> 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
>>
>> 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> 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>
>> 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> 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
>>>
>>> On Sun, Dec 6, 2015 at 8:10 PM, Erica Sadun <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/
>>>> ).
>>>>
>>>> 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> 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
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>
>>>>
>>>>
>>>
>>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>  _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> 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/42b7f011/attachment.html>