[swift-evolution] Request for Discussion: Setup closures

[Matthew Johnson]

I understand it's a hypothetical.  I posted a very rough sketch of a mechanism for doing this last night in a different thread.

I'm working on a more fleshed out proposal right now.  I won't have time to finish it tonight.  I hope to finish it in the next day or two and will share it as soon as I have fleshed it out enough to serve as a stake in the ground for discussion.

Sent from my iPad

> On Dec 6, 2015, at 10:08 PM, David Waite <david at alkaline-solutions.com> wrote:
> 
> This is not something anyone else can evaluate, as you haven’t shared details on your alternate proposal.
> 
> -DW
> 
>> On Dec 6, 2015, at 7:27 PM, Matthew Johnson via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> In thinking about this further I think I can summarize my position pretty concisely.  
>> 
>> A criteria that has been used quite a bit in the feature removal threads and proposals is "if this feature was not already in the language would we add it".  I am using a variation of this criteria and asking "if Swift had a feature facilitating more flexible initialization and we could use that feature with Cocoa would we still want to add setup closures?".  I don't think we would.
>> 
>> Sent from my iPad
>> 
>>> On Dec 6, 2015, at 8:04 PM, Matthew Johnson via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> I do agree that current approaches are a bit ugly, that they are common in Cocoa code, and that the proposal cleans this up.  I would even enjoy the cleaner syntax in my own code if the feature was adopted.
>>> 
>>> However, I share Jacob's thought that focusing on improving initialization flexibility is where we should focus.  I think it is a better use of our time, effort and language feature "budget".  This might be a more complex problem to solve, but the payoff is much larger in the end.
>>> 
>>> Ideally instances should be fully configured for their intended use when initialization completes.  I view the *need* for post-initialization setup as a deficiency in the language, the interface of the type, or both (even if a type must expose members that are mutated by users during the lifetime of an instance it should still be possible to fully configure an instance for its initial use during initialization).  
>>> 
>>> If we can remove the aforementioned deficiency we will not need "setup closures". Doing this will require a language feature as well as a way to take advantage of the new feature when using Cocoa (probably through the Objective-C API import mechanism).
>>> 
>>> We obviously need to begin with the language feature so that is where I'm focusing right now.  I plan to write a first draft of a proposal soon.
>>> 
>>> All of this aside, I am still interest in hearing about additional use cases for the "method cascade" idea.  If it is more broadly applicable I might find it more worthwhile.
>>> 
>>> Sent from my iPhone
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151206/86b26e34/attachment.html>