Propose for inclusion in swift-lang

[Ashton-W]

I think this library and pattern is 'swifty' enough to be part of Swift-lang itself!

Perhaps the syntax would change to be like an auto closure.
I speculate the compiler could do something with value-types being treated as immutable after being returned in some cases.

[devxoul]

Awesome, sounds interesting. What could I do?

[Ashton-W]

Start a thread on the mailing list to see what other people think, and start writing the proposal using the swift evolution template. Best of luck

[devxoul]

Thank you! I'll take a look soon 😄

[jyounus]

If you do create a proposal, it would be better if Swift would do this without having to use the ".then" part (or maybe it was named something else).

The reason for that is because I love to use "Promises" for any async operations (take a look at a lib like PromiseKit http://promisekit.org/ ). Promises usually use .then(), so I'm not sure if there would be conflicts when using this lib.

[adrfer]

@devxoul I'd suggest you to take a look at this thread https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151228/005122.html

@jyounus there's a pull request by @basvankuijck that provides an alternate syntax

[devxoul]

@adrfer, Cool. Someone has already done it. How can I lend weight to this suggestion?

[adrfer]

@devxoul perhaps, after reading the related threads, take a look at @erica's https://gist.github.com/erica/eb32feb22ba99629285a

Sure you guys can put together and submit a great proposal 👌

[wcatron]

@adrfer Thanks for making everyone aware of each other! @devxoul Done it? Far from it, but please do contribute on the mailing list. @erica's proposal looks nearly complete but I could not find it submitted on the Swift Evolution Repo and has not been edited for a few weeks (Need some collaborators?). We each have slightly different models with different goals. Here is the Then example code in the three different styles:

Mailing List "Inline Initializer" Restricted to initializers similar to then. However it acts as an initializer compared to code after (possible advantages). Also avoids $0 and has some ideas for handling self.

let label = UILabel {
    textAlignment = .Center
    textColor = .blackColor()
    text = "Hello, World!"
}

@erica's "Method Cascading" More comprehensive "method cascading" proposal. Applies to much more than initializers. Introduces "with" keyword. self is the label object.

with let label = UILabel() {
    textAlignment = .Center
    textColor = .blackColor()
    text = "Hello, World!"
}

Then Possible syntax proposal, not sure how you were envisioning it but this is similar to how you had it. Maintains self.

let label = UILabel() then {
    label.textAlignment = .Center
    label.textColor = .blackColor()
    label.text = "Hello, World!"
}

So can we come to an agreement, create a proposal, and submit it for review? Perhaps we can build off of the "Method Cascading" and bring in maintaining self and drop the with keyword? Perhaps the with is only required when self is desired?

[NicholasTD07]

Then, or the concept of Inline Initializer, really looked very promising at first glance to me. Because in many projects I set properties of a UI in its lazy initialization.

However, soon I found out that compared to lazy initialization of a var, then is almost useless in most of my use cases because you cannot reference self in a then block but you can do that in lazy initialization blocks.

For example, I can reference another instance var in a controller or a view, or assign the controller itself self to be the datasource or the delegate of a UITableView or UICollectionView, when using lazy initialization blocks.

[erica]

Chris Lattner asked that it be submitted as a bug report instead of advancing as a proposal. It was. https://bugs.swift.org/browse/SR-160 https://bugs.swift.org/browse/SR-160

-- E

On Jan 4, 2016, at 2:20 AM, Nicholas T. notifications@github.com wrote:

Then, or the concept of Inline Initializer, really looked very promising at first glance to me. Because in many projects I set properties of a UI in its lazy initialization.

However, soon I found out that compared to lazy initialization of a var, then is almost useless in most use cases because you cannot reference self in a then block but you can do that in lazy initialization blocks.

For example, I can reference another instance var in a controller or a view, or assign the controller itself self to be the datasource or the delegate of a UITableView or UICollectionView, when using lazy initialization blocks.

—
Reply to this email directly or view it on GitHub #2 (comment).

[devxoul]

@wcatron, thanks for asking. Of course I hope it to be adopted to Swift grammar 😄

[rv-17]

It would be much less a PITA to have something like Kotlin's with() plus IDE support.