[swift-evolution] Request for Discussion: Setup closures

[ilya]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151206/4bb27359/attachment.html>