Propose for inclusion in swift-lang #2

Activity

1. devxoul commented on Dec 30, 2015

   

   devxoul

   on Dec 30, 2015

   Owner

   More actions

   Awesome, sounds interesting. What could I do?
2. Ashton-W commented on Dec 30, 2015

   

   Ashton-W

   on Dec 30, 2015

   Author

   More actions

   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
3. devxoul commented on Dec 30, 2015

   

   devxoul

   on Dec 30, 2015

   Owner

   More actions

   Thank you! I'll take a look soon 😄
4. jyounus commented on Jan 3, 2016

   

   jyounus

   on Jan 3, 2016

   More actions

   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.

   👍React with 👍1Reacted by Linus Unnebäck
5. adrfer commented on Jan 4, 2016

   

   adrfer

   on Jan 4, 2016

   More actions

   @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
6. devxoul commented on Jan 4, 2016

   

   devxoul

   on Jan 4, 2016

   Owner

   More actions

   @adrfer, Cool. Someone has already done it. How can I lend weight to this suggestion?
7. adrfer commented on Jan 4, 2016

   

   adrfer

   on Jan 4, 2016

   More actions

   @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 👌
8. wcatron commented on Jan 4, 2016

   

   wcatron

   on Jan 4, 2016

   More actions

   @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?

   👍React with 👍1Reacted by 王哼哼
9. NicholasTD07 commented on Jan 4, 2016

   

   NicholasTD07

   on Jan 4, 2016

   More actions

   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.
10. erica commented on Jan 4, 2016

    

    erica

    on Jan 4, 2016

    More actions

    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).
11. devxoul commented on Jan 4, 2016

    

    devxoul

    on Jan 4, 2016

    Owner

    More actions

    @wcatron, thanks for asking. Of course I hope it to be adopted to Swift grammar 😄
12. rv-17 commented on Feb 8, 2017

    

    rv-17

    on Feb 8, 2017

    More actions

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