Request for Discussion: Setup closures

[anandabits (Matthew Johnson)]

Thanks for the links Erica. I appreciate your sharing them.

A lot of the examples in these articles are variations on the initialization problem (which I believe is better solved in other ways).

The other major use case appears to be DSLs (I consider the graphics code examples to be effectively a DSL for hard-coding graphics data). If one of the major use cases for method cascades is to create DSLs I think part of the discussion needs to address the question of whether or not this is the best tool to use to create DSLs in Swift (or at least certain classes of DSL). If the answer is yes then I it becomes pretty easy for this feature to demonstrate its merit. If Swift has (or can have) better tools for creating DSLs (hygienic macros?) then I think we need to look to other use cases to justify method cascades.

There were a few examples that don’t really fall into either of the two categories. There is no doubt that this feature would reduce syntactic clutter in some code that could not be eliminated by any other feature. Maybe they are pervasive enough to warrant language support and maybe not. I haven’t seen enough real-world examples to convince me yet, but am keeping my mind open and looking forward to seeing more.

···

On Dec 6, 2015, at 8:45 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

Please note that the updated topic is no longer setup closures, which I have been convinced is the less compelling of the two related concepts, but method cascading.

Rather than re-invent the wheel, let me offer this reading list:

Dart language feature request: method cascades <Dart language feature request: method cascades - Google Docs;
Method Cascades in Dart <http://news.dartlang.org/2012/02/method-cascades-in-dart-posted-by-gilad.html&gt;
8 Dart Features / Fluent APIs <http://radar.oreilly.com/2013/05/8-dart-features-those-fat-cats-dont-want-you-to-know.html&gt;
Dart-like method cascading operator in Python <https://mail.python.org/pipermail//python-ideas/2013-November/024124.html&gt;
Method Cascades (in Smalltalk) <http://devblog.avdi.org/2011/09/26/sbpp-4-method-cascades/&gt;

-- E

On Dec 6, 2015, at 7:04 PM, Matthew Johnson <matthew@anandabits.com <mailto:matthew@anandabits.com>> 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

On Dec 6, 2015, at 3:13 PM, Jacob Bandes-Storch via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

It seems like setting properties just after init is the main use case here.

I'm not against this idea, but I want to point out that this doesn't *need* to be solved by a change to the language. You can easily define a convenience init for UILabel that takes textAlignment, font, text, and numberOfLines as parameters. They could have default values so you can specify just the ones you need.

I like the idea of being able to do configure objects/values conveniently, but I'm not sure how to justify a language change for it. Perhaps we just need better autogeneration of initializers during Obj-C header import.

Jacob Bandes-Storch

On Sun, Dec 6, 2015 at 1:06 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Do you want me to tweak that? Or remove it entirely? Also, I think I forgot to name-drop you slightly earlier as well

On Dec 6, 2015, at 2:04 PM, David Waite <david@alkaline-solutions.com <mailto:david@alkaline-solutions.com>> wrote:

I’m leaning away from “self in” style syntax - I think there are too many cases where you still want to be able to bind and access the self of the object your closure was declared within.

I’m not sure you have to establish a new “self” however - have the type of object given to with is known, so the methods/functions available to it can be exposed as lexical scope.

To keep code clarity, use of methods/functions which shadow something in higher lexical scope should likely result in compiler errors.

-DW

On Dec 6, 2015, at 1:48 PM, ilya via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

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@swift.org <mailto:swift-evolution@swift.org>> wrote:
It's probably better at this point for me to collect my thoughts and summarize where I am at.

cascade.md · GitHub

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@gmail.com <mailto:ilya.nikokoshev@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@ericasadun.com <mailto:erica@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@gmail.com <mailto:ilya.nikokoshev@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@ericasadun.com <mailto:erica@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[Erica_Sadun]

Could you take a peek please at my updated writeup for a potential proposal here: cascade.md · GitHub

Thanks, -- E

···

On Dec 6, 2015, at 8:12 PM, Matthew Johnson <matthew@anandabits.com> wrote:

Thanks for the links Erica. I appreciate your sharing them.

A lot of the examples in these articles are variations on the initialization problem (which I believe is better solved in other ways).

The other major use case appears to be DSLs (I consider the graphics code examples to be effectively a DSL for hard-coding graphics data). If one of the major use cases for method cascades is to create DSLs I think part of the discussion needs to address the question of whether or not this is the best tool to use to create DSLs in Swift (or at least certain classes of DSL). If the answer is yes then I it becomes pretty easy for this feature to demonstrate its merit. If Swift has (or can have) better tools for creating DSLs (hygienic macros?) then I think we need to look to other use cases to justify method cascades.

There were a few examples that don’t really fall into either of the two categories. There is no doubt that this feature would reduce syntactic clutter in some code that could not be eliminated by any other feature. Maybe they are pervasive enough to warrant language support and maybe not. I haven’t seen enough real-world examples to convince me yet, but am keeping my mind open and looking forward to seeing more.

On Dec 6, 2015, at 8:45 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Please note that the updated topic is no longer setup closures, which I have been convinced is the less compelling of the two related concepts, but method cascading.

Rather than re-invent the wheel, let me offer this reading list:

Dart language feature request: method cascades <Dart language feature request: method cascades - Google Docs;
Method Cascades in Dart <http://news.dartlang.org/2012/02/method-cascades-in-dart-posted-by-gilad.html&gt;
8 Dart Features / Fluent APIs <http://radar.oreilly.com/2013/05/8-dart-features-those-fat-cats-dont-want-you-to-know.html&gt;
Dart-like method cascading operator in Python <https://mail.python.org/pipermail//python-ideas/2013-November/024124.html&gt;
Method Cascades (in Smalltalk) <http://devblog.avdi.org/2011/09/26/sbpp-4-method-cascades/&gt;

-- E

On Dec 6, 2015, at 7:04 PM, Matthew Johnson <matthew@anandabits.com <mailto:matthew@anandabits.com>> 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

On Dec 6, 2015, at 3:13 PM, Jacob Bandes-Storch via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

It seems like setting properties just after init is the main use case here.

I'm not against this idea, but I want to point out that this doesn't *need* to be solved by a change to the language. You can easily define a convenience init for UILabel that takes textAlignment, font, text, and numberOfLines as parameters. They could have default values so you can specify just the ones you need.

I like the idea of being able to do configure objects/values conveniently, but I'm not sure how to justify a language change for it. Perhaps we just need better autogeneration of initializers during Obj-C header import.

Jacob Bandes-Storch

On Sun, Dec 6, 2015 at 1:06 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Do you want me to tweak that? Or remove it entirely? Also, I think I forgot to name-drop you slightly earlier as well

On Dec 6, 2015, at 2:04 PM, David Waite <david@alkaline-solutions.com <mailto:david@alkaline-solutions.com>> wrote:

I’m leaning away from “self in” style syntax - I think there are too many cases where you still want to be able to bind and access the self of the object your closure was declared within.

I’m not sure you have to establish a new “self” however - have the type of object given to with is known, so the methods/functions available to it can be exposed as lexical scope.

To keep code clarity, use of methods/functions which shadow something in higher lexical scope should likely result in compiler errors.

-DW

On Dec 6, 2015, at 1:48 PM, ilya via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

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@swift.org <mailto:swift-evolution@swift.org>> wrote:
It's probably better at this point for me to collect my thoughts and summarize where I am at.

cascade.md · GitHub

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@gmail.com <mailto:ilya.nikokoshev@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@ericasadun.com <mailto:erica@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@gmail.com <mailto:ilya.nikokoshev@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@ericasadun.com <mailto:erica@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

[anandabits (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@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@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@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

[Lukas_Stabe]

The proposal sounds like a good start to me. I really like the idea of this feature (and have in the past in obj-c used the compound-statement-expression gnu extension to achieve similar-looking code).

One thing I found myself thinking about is: How would `with` work when used with optionals (think failable initializers)? Would the block just not be executed (making it similar to mapping over an optional)? That would sound like a big plus for this feature, since you wouldn’t need to either use optional chaining or check if the value was nil while doing further setup.

Another question for me is this: Say I want to create an instance of a class, configure it, and then assign it to a property on some other object (it can’t be assigned before it’s fully configured). Could we adapt this proposal to handle that case, too (e.g. `with obj.prop = MyClass() { … }`)? I think it might feel more natural to move the `with` after the assignment (e.g. `obj.prop = with MyClass() { … }, so it could be used not just to assign to a local variable but in any context you want to use it, including method calls etc.

Lukas

···

On 07 Dec 2015, at 04:27, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

Could you take a peek please at my updated writeup for a potential proposal here: cascade.md · GitHub

Thanks, -- E

On Dec 6, 2015, at 8:12 PM, Matthew Johnson <matthew@anandabits.com <mailto:matthew@anandabits.com>> wrote:

Thanks for the links Erica. I appreciate your sharing them.

A lot of the examples in these articles are variations on the initialization problem (which I believe is better solved in other ways).

The other major use case appears to be DSLs (I consider the graphics code examples to be effectively a DSL for hard-coding graphics data). If one of the major use cases for method cascades is to create DSLs I think part of the discussion needs to address the question of whether or not this is the best tool to use to create DSLs in Swift (or at least certain classes of DSL). If the answer is yes then I it becomes pretty easy for this feature to demonstrate its merit. If Swift has (or can have) better tools for creating DSLs (hygienic macros?) then I think we need to look to other use cases to justify method cascades.

There were a few examples that don’t really fall into either of the two categories. There is no doubt that this feature would reduce syntactic clutter in some code that could not be eliminated by any other feature. Maybe they are pervasive enough to warrant language support and maybe not. I haven’t seen enough real-world examples to convince me yet, but am keeping my mind open and looking forward to seeing more.

On Dec 6, 2015, at 8:45 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Please note that the updated topic is no longer setup closures, which I have been convinced is the less compelling of the two related concepts, but method cascading.

Rather than re-invent the wheel, let me offer this reading list:

Dart language feature request: method cascades <Dart language feature request: method cascades - Google Docs;
Method Cascades in Dart <http://news.dartlang.org/2012/02/method-cascades-in-dart-posted-by-gilad.html&gt;
8 Dart Features / Fluent APIs <http://radar.oreilly.com/2013/05/8-dart-features-those-fat-cats-dont-want-you-to-know.html&gt;
Dart-like method cascading operator in Python <https://mail.python.org/pipermail//python-ideas/2013-November/024124.html&gt;
Method Cascades (in Smalltalk) <http://devblog.avdi.org/2011/09/26/sbpp-4-method-cascades/&gt;

-- E

On Dec 6, 2015, at 7:04 PM, Matthew Johnson <matthew@anandabits.com <mailto:matthew@anandabits.com>> 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

On Dec 6, 2015, at 3:13 PM, Jacob Bandes-Storch via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

It seems like setting properties just after init is the main use case here.

I'm not against this idea, but I want to point out that this doesn't *need* to be solved by a change to the language. You can easily define a convenience init for UILabel that takes textAlignment, font, text, and numberOfLines as parameters. They could have default values so you can specify just the ones you need.

I like the idea of being able to do configure objects/values conveniently, but I'm not sure how to justify a language change for it. Perhaps we just need better autogeneration of initializers during Obj-C header import.

Jacob Bandes-Storch

On Sun, Dec 6, 2015 at 1:06 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Do you want me to tweak that? Or remove it entirely? Also, I think I forgot to name-drop you slightly earlier as well

On Dec 6, 2015, at 2:04 PM, David Waite <david@alkaline-solutions.com <mailto:david@alkaline-solutions.com>> wrote:

I’m leaning away from “self in” style syntax - I think there are too many cases where you still want to be able to bind and access the self of the object your closure was declared within.

I’m not sure you have to establish a new “self” however - have the type of object given to with is known, so the methods/functions available to it can be exposed as lexical scope.

To keep code clarity, use of methods/functions which shadow something in higher lexical scope should likely result in compiler errors.

-DW

On Dec 6, 2015, at 1:48 PM, ilya via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

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@swift.org <mailto:swift-evolution@swift.org>> wrote:
It's probably better at this point for me to collect my thoughts and summarize where I am at.

cascade.md · GitHub

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@gmail.com <mailto:ilya.nikokoshev@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@ericasadun.com <mailto:erica@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@gmail.com <mailto:ilya.nikokoshev@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@ericasadun.com <mailto:erica@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[thorsten (thorsten@portableinnovations.de)]

I'm against adding this.

Let me try to explain why:
- the proposal creates several ambiguities (as pointed out by Michael Fortin) which make the code difficult to read and can even introduce errors.
- Disambiguating with "self" does not work IMHO because this is ambiguous with the "self" from the enclosing context and easily confused. To disambiguate outer self references you would have to use e.g. "outer" to reference the outer self which adds even more clutter.
- the alternative proposed for solving these problems which requires leading dots for self-references decreases readability because the dots ar easily missed, especially because they may appear anywhere within each line as demonstrated by rhe example in the proposal
- the alternatives proposed by Jacob Bandes-Storch (defining a convenience init) and David Waite (using a simple closure) both do not need a language extension and solve the problems cited just as easily or even better: the closure even looks almost like the proposal except for the in-clause but does not suffer from the ambiguity problems or the potential of introducing errors or readability problems.

-Thorsten

···

Am 07.12.2015 um 04:27 schrieb Erica Sadun via swift-evolution <swift-evolution@swift.org>:

Could you take a peek please at my updated writeup for a potential proposal here: cascade.md · GitHub

Thanks, -- E

On Dec 6, 2015, at 8:12 PM, Matthew Johnson <matthew@anandabits.com> wrote:

Thanks for the links Erica. I appreciate your sharing them.

A lot of the examples in these articles are variations on the initialization problem (which I believe is better solved in other ways).

The other major use case appears to be DSLs (I consider the graphics code examples to be effectively a DSL for hard-coding graphics data). If one of the major use cases for method cascades is to create DSLs I think part of the discussion needs to address the question of whether or not this is the best tool to use to create DSLs in Swift (or at least certain classes of DSL). If the answer is yes then I it becomes pretty easy for this feature to demonstrate its merit. If Swift has (or can have) better tools for creating DSLs (hygienic macros?) then I think we need to look to other use cases to justify method cascades.

There were a few examples that don’t really fall into either of the two categories. There is no doubt that this feature would reduce syntactic clutter in some code that could not be eliminated by any other feature. Maybe they are pervasive enough to warrant language support and maybe not. I haven’t seen enough real-world examples to convince me yet, but am keeping my mind open and looking forward to seeing more.

On Dec 6, 2015, at 8:45 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

Please note that the updated topic is no longer setup closures, which I have been convinced is the less compelling of the two related concepts, but method cascading.

Rather than re-invent the wheel, let me offer this reading list:

Dart language feature request: method cascades
Method Cascades in Dart
8 Dart Features / Fluent APIs
Dart-like method cascading operator in Python
Method Cascades (in Smalltalk)

-- E

On Dec 6, 2015, at 7:04 PM, Matthew Johnson <matthew@anandabits.com> 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

On Dec 6, 2015, at 3:13 PM, Jacob Bandes-Storch via swift-evolution <swift-evolution@swift.org> wrote:

It seems like setting properties just after init is the main use case here.

I'm not against this idea, but I want to point out that this doesn't *need* to be solved by a change to the language. You can easily define a convenience init for UILabel that takes textAlignment, font, text, and numberOfLines as parameters. They could have default values so you can specify just the ones you need.

I like the idea of being able to do configure objects/values conveniently, but I'm not sure how to justify a language change for it. Perhaps we just need better autogeneration of initializers during Obj-C header import.

Jacob Bandes-Storch

On Sun, Dec 6, 2015 at 1:06 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:
Do you want me to tweak that? Or remove it entirely? Also, I think I forgot to name-drop you slightly earlier as well

On Dec 6, 2015, at 2:04 PM, David Waite <david@alkaline-solutions.com> wrote:

I’m leaning away from “self in” style syntax - I think there are too many cases where you still want to be able to bind and access the self of the object your closure was declared within.

I’m not sure you have to establish a new “self” however - have the type of object given to with is known, so the methods/functions available to it can be exposed as lexical scope.

To keep code clarity, use of methods/functions which shadow something in higher lexical scope should likely result in compiler errors.

-DW

On Dec 6, 2015, at 1:48 PM, ilya via swift-evolution <swift-evolution@swift.org> wrote:

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@swift.org> wrote:
It's probably better at this point for me to collect my thoughts and summarize where I am at.

cascade.md · GitHub

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@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@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@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@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[Chris_Lattner]

My brief opinion about this:

- Doing something along this lines someday could be interesting.
- This is a pure syntactic extension.
- We have lots of other problems to solve (e.g. making the existing core feature set great), and limited bandwidth.
- I’d recommend deferring work on this until after Swift 3 is winding down.

-Chris

···

On Dec 6, 2015, at 7:27 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

Could you take a peek please at my updated writeup for a potential proposal here: cascade.md · GitHub

[Alex_Lew1 (Alex Lew)]

Thanks for writing this up, Erica! +1 to method cascading and to Lukas's
idea of moving the `with` keyword to after the = sign, so that `with thing
{ ... }` just becomes an expression.

Some q's:

1. Have we thought about how the syntax would work with initializers that
take closures as their last arguments? Would you just no longer use
trailing closure syntax with them?

2. Erica, I'm curious to hear your thoughts on using Dart's .. style of
method cascading, which is mentioned in the proposal but not seriously
considered. It seems it would avoid the difficulties described in the
proposal (about what to do when names are both in outer scope and members
of newly bound self).

···

On Sun, Dec 6, 2015 at 10:47 PM, Lukas Stabe via swift-evolution < swift-evolution@swift.org> wrote:

The proposal sounds like a good start to me. I really like the idea of
this feature (and have in the past in obj-c used the
compound-statement-expression gnu extension to achieve similar-looking
code).

One thing I found myself thinking about is: How would `with` work when
used with optionals (think failable initializers)? Would the block just not
be executed (making it similar to mapping over an optional)? That would
sound like a big plus for this feature, since you wouldn’t need to either
use optional chaining or check if the value was nil while doing further
setup.

Another question for me is this: Say I want to create an instance of a
class, configure it, and then assign it to a property on some other object
(it can’t be assigned before it’s fully configured). Could we adapt this
proposal to handle that case, too (e.g. `with obj.prop = MyClass() { … }`)?
I think it might feel more natural to move the `with` after the assignment
(e.g. `obj.prop = with MyClass() { … }, so it could be used not just to
assign to a local variable but in any context you want to use it, including
method calls etc.

Lukas

On 07 Dec 2015, at 04:27, Erica Sadun via swift-evolution < > swift-evolution@swift.org> wrote:

Could you take a peek please at my updated writeup for a potential
proposal here: cascade.md · GitHub

Thanks, -- E

On Dec 6, 2015, at 8:12 PM, Matthew Johnson < matthew@anandabits.com> > wrote:

Thanks for the links Erica. I appreciate your sharing them.

A lot of the examples in these articles are variations on the
initialization problem (which I believe is better solved in other ways).

The other major use case appears to be DSLs (I consider the graphics code
examples to be effectively a DSL for hard-coding graphics data). If one of
the major use cases for method cascades is to create DSLs I think part of
the discussion needs to address the question of whether or not this is the
best tool to use to create DSLs in Swift (or at least certain classes of
DSL). If the answer is yes then I it becomes pretty easy for this feature
to demonstrate its merit. If Swift has (or can have) better tools for
creating DSLs (hygienic macros?) then I think we need to look to other use
cases to justify method cascades.

There were a few examples that don’t really fall into either of the two
categories. There is no doubt that this feature would reduce syntactic
clutter in some code that could not be eliminated by any other feature.
Maybe they are pervasive enough to warrant language support and maybe not.
I haven’t seen enough real-world examples to convince me yet, but am
keeping my mind open and looking forward to seeing more.

On Dec 6, 2015, at 8:45 PM, Erica Sadun via swift-evolution < > swift-evolution@swift.org> wrote:

Please note that the updated topic is no longer setup closures, which I
have been convinced is the less compelling of the two related concepts, but
method cascading.

Rather than re-invent the wheel, let me offer this reading list:

   - *Dart language feature request: method cascades*
   <Dart language feature request: method cascades - Google Docs;
   - *Method Cascades in Dart*
   <http://news.dartlang.org/2012/02/method-cascades-in-dart-posted-by-gilad.html&gt;
   - *8 Dart Features / Fluent APIs*
   <http://radar.oreilly.com/2013/05/8-dart-features-those-fat-cats-dont-want-you-to-know.html&gt;
   - Dart-like method cascading operator in Python
   <https://mail.python.org/pipermail//python-ideas/2013-November/024124.html&gt;
   - *Method Cascades (in Smalltalk)*
   <http://devblog.avdi.org/2011/09/26/sbpp-4-method-cascades/&gt;

-- E

On Dec 6, 2015, at 7:04 PM, Matthew Johnson < matthew@anandabits.com> > 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

On Dec 6, 2015, at 3:13 PM, Jacob Bandes-Storch via swift-evolution < > swift-evolution@swift.org> wrote:

It seems like setting properties just after init is the main use case
here.

I'm not against this idea, but I want to point out that this doesn't
*need* to be solved by a change to the language. You can easily define a convenience
init for UILabel that takes textAlignment, font, text, and numberOfLines
as parameters. They could have default values so you can specify just the
ones you need.

I like the idea of being able to do configure objects/values conveniently,
but I'm not sure how to justify a language change for it. Perhaps we just
need better autogeneration of initializers during Obj-C header import.

Jacob Bandes-Storch

On Sun, Dec 6, 2015 at 1:06 PM, Erica Sadun via swift-evolution < > swift-evolution@swift.org> wrote:

Do you want me to tweak that? Or remove it entirely? Also, I think I
forgot to name-drop you slightly earlier as well

On Dec 6, 2015, at 2:04 PM, David Waite < david@alkaline-solutions.com> >> wrote:

I’m leaning away from “self in” style syntax - I think there are too many
cases where you still want to be able to bind and access the self of the
object your closure was declared within.

I’m not sure you have to establish a new “self” however - have the type
of object given to with is known, so the methods/functions available to it
can be exposed as lexical scope.

To keep code clarity, use of methods/functions which shadow something in
higher lexical scope should likely result in compiler errors.

-DW

On Dec 6, 2015, at 1:48 PM, ilya via swift-evolution < >> swift-evolution@swift.org> wrote:

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@swift.org> wrote:

It's probably better at this point for me to collect my thoughts and
summarize where I am at.

cascade.md · GitHub

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@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@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@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@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Untracked with Trackbuster <Your contacts automatically up to date | evercontact;

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[thorsten (thorsten@portableinnovations.de)]

I might add to my mail below that I come from a Smalltalk background and love the cascades there, but the problem with the proposal is that it goes beyond simple cascades, i.e. method calls to the same receiver, and wants to create a context where the receiver is implicitly given.

-Thorsten

···

Am 07.12.2015 um 07:32 schrieb thorsten--- via swift-evolution <swift-evolution@swift.org>:

I'm against adding this.

Let me try to explain why:
- the proposal creates several ambiguities (as pointed out by Michael Fortin) which make the code difficult to read and can even introduce errors.
- Disambiguating with "self" does not work IMHO because this is ambiguous with the "self" from the enclosing context and easily confused. To disambiguate outer self references you would have to use e.g. "outer" to reference the outer self which adds even more clutter.
- the alternative proposed for solving these problems which requires leading dots for self-references decreases readability because the dots ar easily missed, especially because they may appear anywhere within each line as demonstrated by rhe example in the proposal
- the alternatives proposed by Jacob Bandes-Storch (defining a convenience init) and David Waite (using a simple closure) both do not need a language extension and solve the problems cited just as easily or even better: the closure even looks almost like the proposal except for the in-clause but does not suffer from the ambiguity problems or the potential of introducing errors or readability problems.

-Thorsten

Am 07.12.2015 um 04:27 schrieb Erica Sadun via swift-evolution <swift-evolution@swift.org>:

Could you take a peek please at my updated writeup for a potential proposal here: cascade.md · GitHub

Thanks, -- E

On Dec 6, 2015, at 8:12 PM, Matthew Johnson <matthew@anandabits.com> wrote:

Thanks for the links Erica. I appreciate your sharing them.

A lot of the examples in these articles are variations on the initialization problem (which I believe is better solved in other ways).

The other major use case appears to be DSLs (I consider the graphics code examples to be effectively a DSL for hard-coding graphics data). If one of the major use cases for method cascades is to create DSLs I think part of the discussion needs to address the question of whether or not this is the best tool to use to create DSLs in Swift (or at least certain classes of DSL). If the answer is yes then I it becomes pretty easy for this feature to demonstrate its merit. If Swift has (or can have) better tools for creating DSLs (hygienic macros?) then I think we need to look to other use cases to justify method cascades.

There were a few examples that don’t really fall into either of the two categories. There is no doubt that this feature would reduce syntactic clutter in some code that could not be eliminated by any other feature. Maybe they are pervasive enough to warrant language support and maybe not. I haven’t seen enough real-world examples to convince me yet, but am keeping my mind open and looking forward to seeing more.

On Dec 6, 2015, at 8:45 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

Please note that the updated topic is no longer setup closures, which I have been convinced is the less compelling of the two related concepts, but method cascading.

Rather than re-invent the wheel, let me offer this reading list:

Dart language feature request: method cascades
Method Cascades in Dart
8 Dart Features / Fluent APIs
Dart-like method cascading operator in Python
Method Cascades (in Smalltalk)

-- E

On Dec 6, 2015, at 7:04 PM, Matthew Johnson <matthew@anandabits.com> 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

On Dec 6, 2015, at 3:13 PM, Jacob Bandes-Storch via swift-evolution <swift-evolution@swift.org> wrote:

It seems like setting properties just after init is the main use case here.

I'm not against this idea, but I want to point out that this doesn't *need* to be solved by a change to the language. You can easily define a convenience init for UILabel that takes textAlignment, font, text, and numberOfLines as parameters. They could have default values so you can specify just the ones you need.

I like the idea of being able to do configure objects/values conveniently, but I'm not sure how to justify a language change for it. Perhaps we just need better autogeneration of initializers during Obj-C header import.

Jacob Bandes-Storch

On Sun, Dec 6, 2015 at 1:06 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:
Do you want me to tweak that? Or remove it entirely? Also, I think I forgot to name-drop you slightly earlier as well

On Dec 6, 2015, at 2:04 PM, David Waite <david@alkaline-solutions.com> wrote:

I’m leaning away from “self in” style syntax - I think there are too many cases where you still want to be able to bind and access the self of the object your closure was declared within.

I’m not sure you have to establish a new “self” however - have the type of object given to with is known, so the methods/functions available to it can be exposed as lexical scope.

To keep code clarity, use of methods/functions which shadow something in higher lexical scope should likely result in compiler errors.

-DW

On Dec 6, 2015, at 1:48 PM, ilya via swift-evolution <swift-evolution@swift.org> wrote:

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@swift.org> wrote:
It's probably better at this point for me to collect my thoughts and summarize where I am at.

cascade.md · GitHub

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@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@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@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@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[anandabits (Matthew Johnson)]

Another potential reason to hold off on this proposal is that hygienic macros have been mentioned by the core team enough times that it's reasonable to think they will likely be a part of Swift in the future.

If that does happen it may be possible to implement something like this as a macro. That would allow the community to experiment with ideas and gain some experience before a commitment is made to add something to the standard library.

I've never worked in a language with a good macro system so I'm hoping others can chime in on the feasibility of implementing this in a macro. It seems likely to be possible but I'm not an expert in this area.

···

Sent from my iPad

On Dec 7, 2015, at 12:32 AM, "thorsten@portableinnovations.de" <thorsten@portableinnovations.de> wrote:

I'm against adding this.

Let me try to explain why:
- the proposal creates several ambiguities (as pointed out by Michael Fortin) which make the code difficult to read and can even introduce errors.
- Disambiguating with "self" does not work IMHO because this is ambiguous with the "self" from the enclosing context and easily confused. To disambiguate outer self references you would have to use e.g. "outer" to reference the outer self which adds even more clutter.
- the alternative proposed for solving these problems which requires leading dots for self-references decreases readability because the dots ar easily missed, especially because they may appear anywhere within each line as demonstrated by rhe example in the proposal
- the alternatives proposed by Jacob Bandes-Storch (defining a convenience init) and David Waite (using a simple closure) both do not need a language extension and solve the problems cited just as easily or even better: the closure even looks almost like the proposal except for the in-clause but does not suffer from the ambiguity problems or the potential of introducing errors or readability problems.

-Thorsten

Am 07.12.2015 um 04:27 schrieb Erica Sadun via swift-evolution <swift-evolution@swift.org>:

Could you take a peek please at my updated writeup for a potential proposal here: cascade.md · GitHub

Thanks, -- E

On Dec 6, 2015, at 8:12 PM, Matthew Johnson <matthew@anandabits.com> wrote:

Thanks for the links Erica. I appreciate your sharing them.

A lot of the examples in these articles are variations on the initialization problem (which I believe is better solved in other ways).

The other major use case appears to be DSLs (I consider the graphics code examples to be effectively a DSL for hard-coding graphics data). If one of the major use cases for method cascades is to create DSLs I think part of the discussion needs to address the question of whether or not this is the best tool to use to create DSLs in Swift (or at least certain classes of DSL). If the answer is yes then I it becomes pretty easy for this feature to demonstrate its merit. If Swift has (or can have) better tools for creating DSLs (hygienic macros?) then I think we need to look to other use cases to justify method cascades.

There were a few examples that don’t really fall into either of the two categories. There is no doubt that this feature would reduce syntactic clutter in some code that could not be eliminated by any other feature. Maybe they are pervasive enough to warrant language support and maybe not. I haven’t seen enough real-world examples to convince me yet, but am keeping my mind open and looking forward to seeing more.

On Dec 6, 2015, at 8:45 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

Please note that the updated topic is no longer setup closures, which I have been convinced is the less compelling of the two related concepts, but method cascading.

Rather than re-invent the wheel, let me offer this reading list:

Dart language feature request: method cascades
Method Cascades in Dart
8 Dart Features / Fluent APIs
Dart-like method cascading operator in Python
Method Cascades (in Smalltalk)

-- E

On Dec 6, 2015, at 7:04 PM, Matthew Johnson <matthew@anandabits.com> 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

On Dec 6, 2015, at 3:13 PM, Jacob Bandes-Storch via swift-evolution <swift-evolution@swift.org> wrote:

It seems like setting properties just after init is the main use case here.

I'm not against this idea, but I want to point out that this doesn't *need* to be solved by a change to the language. You can easily define a convenience init for UILabel that takes textAlignment, font, text, and numberOfLines as parameters. They could have default values so you can specify just the ones you need.

I like the idea of being able to do configure objects/values conveniently, but I'm not sure how to justify a language change for it. Perhaps we just need better autogeneration of initializers during Obj-C header import.

Jacob Bandes-Storch

On Sun, Dec 6, 2015 at 1:06 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:
Do you want me to tweak that? Or remove it entirely? Also, I think I forgot to name-drop you slightly earlier as well

On Dec 6, 2015, at 2:04 PM, David Waite <david@alkaline-solutions.com> wrote:

I’m leaning away from “self in” style syntax - I think there are too many cases where you still want to be able to bind and access the self of the object your closure was declared within.

I’m not sure you have to establish a new “self” however - have the type of object given to with is known, so the methods/functions available to it can be exposed as lexical scope.

To keep code clarity, use of methods/functions which shadow something in higher lexical scope should likely result in compiler errors.

-DW

On Dec 6, 2015, at 1:48 PM, ilya via swift-evolution <swift-evolution@swift.org> wrote:

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@swift.org> wrote:
It's probably better at this point for me to collect my thoughts and summarize where I am at.

cascade.md · GitHub

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@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@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@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@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[Tino]

Nice to see that most points from my wishlist
are already discussed here ;-)
I didn't even know this feature got a name, but it
would be great for working with graphic contexts
and some orher tasks.

But I would prefer another approach over a new keyword:
context.{
moveTo(x: 23, y: 42)
lineTo(x: 0, y: 0)
}
is quite intuitive to me, and I can't see any downsides so far
(first thought was just braces without the dot, but that
could clash when you want to use the syntax with the
return value of a function, which could have a trailing closure).

Something similiar could be archieved by dropping
void as default return value in favour of self...

···

Von meinem iPhone gesendet

[Erica_Sadun]

Noted. Since an updated proposal is all but ready, could we please have a Swift 4 proposal daycare folder to stick it in, so it doesn't get lost or forgotten?

-- E

···

On Dec 7, 2015, at 3:45 PM, Chris Lattner <clattner@apple.com> wrote:

On Dec 6, 2015, at 7:27 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Could you take a peek please at my updated writeup for a potential proposal here: cascade.md · GitHub

My brief opinion about this:

- Doing something along this lines someday could be interesting.
- This is a pure syntactic extension.
- We have lots of other problems to solve (e.g. making the existing core feature set great), and limited bandwidth.
- I’d recommend deferring work on this until after Swift 3 is winding down.

-Chris

[anandabits (Matthew Johnson)]

My brief opinion about this:

- Doing something along this lines someday could be interesting.
- This is a pure syntactic extension.
- We have lots of other problems to solve (e.g. making the existing core feature set great), and limited bandwidth.
- I’d recommend deferring work on this until after Swift 3 is winding down.

That's pretty much how I feel as well. It's not a bad idea but there are more important things to focus on right now with a lot bigger payoffs.

Chris, do you think this could be implemented as a macro in a hypothetical post-3.0 version of Swift?

Matthew

[Brent_Royal-Gordon]

But I would prefer another approach over a new keyword:
context.{
moveTo(x: 23, y: 42)
lineTo(x: 0, y: 0)
}

I would worry that the dot is very, very subtle and easy to miss when reading this code, particularly given that you would expect a space there.

···

--
Brent Royal-Gordon
Architechies

[Erica_Sadun]

Following this weekend's discussions, I'm running a quick poll. It's short.

FEAGTURE WRITE-UP: cascade.md · GitHub
POLL HERE: https://www.surveymonkey.com/r/KFYD5RT

I want to gauge interest in method cascading so I don't push a proposal without reasonably broad support.

Thank you -- Erica

···

On Dec 7, 2015, at 12:08 AM, Tino Heth via swift-evolution <swift-evolution@swift.org> wrote:

Nice to see that most points from my wishlist
are already discussed here ;-)
I didn't even know this feature got a name, but it
would be great for working with graphic contexts
and some orher tasks.

But I would prefer another approach over a new keyword:
context.{
moveTo(x: 23, y: 42)
lineTo(x: 0, y: 0)
}
is quite intuitive to me, and I can't see any downsides so far
(first thought was just braces without the dot, but that
could clash when you want to use the syntax with the
return value of a function, which could have a trailing closure).

Something similiar could be archieved by dropping
void as default return value in favour of self...

Von meinem iPhone gesendet
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[Chris_Lattner]

It totally depends on the design and scope of that macro system, which is completely up for debate (when it comes time to discuss it).

-Chris

···

On Dec 7, 2015, at 4:35 PM, Matthew Johnson <matthew@anandabits.com> wrote:

My brief opinion about this:

- Doing something along this lines someday could be interesting.
- This is a pure syntactic extension.
- We have lots of other problems to solve (e.g. making the existing core feature set great), and limited bandwidth.
- I’d recommend deferring work on this until after Swift 3 is winding down.

That's pretty much how I feel as well. It's not a bad idea but there are more important things to focus on right now with a lot bigger payoffs.

Chris, do you think this could be implemented as a macro in a hypothetical post-3.0 version of Swift?

[maven (Daniel Vollmer)]

Hi,

···

On 8 Dec 2015, at 01:46, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

Noted. Since an updated proposal is all but ready, could we please have a Swift 4 proposal daycare folder to stick it in, so it doesn’t get lost or forgotten?

I thought that’s what the deferred state was for? But there’ll probably quite a few of those if the current “let’s add my favourite feature to Swift”-pace keeps up… So a deferred sub-folder sounds like a good idea IMO.

  Daniel.

[Chris_Lattner]

Personally, I’d rather use bugs.swift.org <Issues · apple/swift · GitHub; for feature requests like this. It is lighter weight, allows commenting, etc.

-Chris

···

On Dec 7, 2015, at 4:46 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

Noted. Since an updated proposal is all but ready, could we please have a Swift 4 proposal daycare folder to stick it in, so it doesn't get lost or forgotten?

[BigZaphod (Sean Heber)]

What I like about the statement “with” variant (obviously biased here) is that it could also, I think, adequately solve the common if-let unwrapping situation that many find cumbersome if “let/var” isn’t assumed to be required to be a part of the construct.

If you used “with” with an optional, it could just skip the entire block if the value was nil. For cases where you only have things to do when the optional is non-nil, and being nil is perfectly okay, this would allow you to pretty naturally write that code without using forced unwrapping or creating a shadowed unwrapped variable.

let foo: MyObject? = nil
with foo {
  .thing = 42
  .otherThing(“meaning of life”)
}

In this case, the entire inner block could just be skipped over since foo is nil. So, I think, not only can this construct address things like initialization chains, I think it can also address the unwrapping tedium too.

It would not change or shadow anything outside the scope of the block, however. If MyObject had a failable initializer, then this would still mean that “bar” is typed MyObject? even if init fails - so it doesn’t unwrap it outside of the block’s scope, but it provides a nice way to safely use an optional without manually unwrapping it:

with let bar = MyObject() {
  .thing = 42
  .otherThing(“meaning of life”)
}

And we could go farther here and end up with something like this:

if with bar {
  <does stuff to bar>
} else {
  <bar was nil>
}
<bar is still typed as optional here>

l8r
Sean

···

On Dec 7, 2015, at 9:41 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

Following this weekend's discussions, I'm running a quick poll. It's short.

FEAGTURE WRITE-UP: cascade.md · GitHub
POLL HERE: https://www.surveymonkey.com/r/KFYD5RT

I want to gauge interest in method cascading so I don't push a proposal without reasonably broad support.

Thank you -- Erica

On Dec 7, 2015, at 12:08 AM, Tino Heth via swift-evolution <swift-evolution@swift.org> wrote:

Nice to see that most points from my wishlist
are already discussed here ;-)
I didn't even know this feature got a name, but it
would be great for working with graphic contexts
and some orher tasks.

But I would prefer another approach over a new keyword:
context.{
moveTo(x: 23, y: 42)
lineTo(x: 0, y: 0)
}
is quite intuitive to me, and I can't see any downsides so far
(first thought was just braces without the dot, but that
could clash when you want to use the syntax with the
return value of a function, which could have a trailing closure).

Something similiar could be archieved by dropping
void as default return value in favour of self...

Von meinem iPhone gesendet
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[Tino]

Thanks for adding my proposal to the poll — I’m already curious about the result.
But one thing to clarify:
I’m not suggesting to use a closure, it’s just a pair of braces that would affect the way functions are identified; only the syntax is different from the „with let“ solution.

[Erica_Sadun]

Here you go: [SR-160] Proposal to introduce Method Cascading · Issue #42782 · apple/swift · GitHub

Let me also point you to this: Swift Cascading.md · GitHub because

* It is pretty
* I put a lot of effort into it, following the "social" request in the current process document, etc
* I want to publicly shower props on Sean Heber, who showed great patience, insight, and kindness helping out on this

I'd appreciate any advice you could share on determining which tool to use when you have a Swift enhancement idea

-- E

···

On Dec 8, 2015, at 10:16 PM, Chris Lattner <clattner@apple.com> wrote:

On Dec 7, 2015, at 4:46 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Noted. Since an updated proposal is all but ready, could we please have a Swift 4 proposal daycare folder to stick it in, so it doesn't get lost or forgotten?

Personally, I’d rather use bugs.swift.org <Issues · apple/swift · GitHub; for feature requests like this. It is lighter weight, allows commenting, etc.

-Chris