-
Notifications
You must be signed in to change notification settings - Fork 291
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Propose for inclusion in swift-lang #2
Comments
Awesome, sounds interesting. What could I do? |
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 |
Thank you! I'll take a look soon 😄 |
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. |
@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 |
@adrfer, Cool. Someone has already done it. How can I lend weight to this suggestion? |
@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 👌 |
@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
@erica's "Method Cascading" More comprehensive "method cascading" proposal. Applies to much more than initializers. Introduces "with" keyword.
Then Possible syntax proposal, not sure how you were envisioning it but this is similar to how you had it. Maintains
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 |
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, For example, I can reference another instance var in a controller or a view, or assign the controller itself |
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
|
@wcatron, thanks for asking. Of course I hope it to be adopted to Swift grammar 😄 |
It would be much less a PITA to have something like Kotlin's with() plus IDE support. |
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.
The text was updated successfully, but these errors were encountered: