Request for Discussion: Setup closures

[ilya]

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?

[anandabits (Matthew Johnson)]

As stated previously, I think a more specific solution is the best way to address the initialization / setup / configuration problem. While that is the case I did think some more about the ideas in this thread.

I believe two things are being proposed here:

1. The ability to append a trailing closure to any initializer (that doesn’t already declare one itself) that accepts a single argument of the initialized type. If the caller supplies such a closure, the compiler performs a code transformation as follows:

let questionLabel = UILabel() {
  $0.textAlignment = .Center
  $0.font = UIFont(name:"DnealianManuscript", size: 72)
  $0.numberOfLines = 0
}

becomes something like this (which is valid Swift today:

let questionLabel = UILabel(); {
  $0.textAlignment = .Center
  $0.font = UIFont(name:"DnealianManuscript", size: 72)
  $0.numberOfLines = 0
}(questionLabel)

The code transformation doesn’t actually buy us much. I’m a big believer in removing the need for clutter and boilerplate as much as possible, but even I must admit that the difference is really small and can be reduced a bit further using currently valid Swift code as demonstrated by the “configuration operator” mentioned in the previous post.

2. A new abbreviation of the $0 shorthand that would be valid only as the first characters on a line of code. For consistency this shorthand should work in any closure, not just in “setup closures”. I agree that $0 is uglier than necessary in this use case which would be relatively common in Cocoa code if this pattern becomes common.

The biggest drawback I can think of to a feature like this is that it is a feature specifically designed to make the use of var members more convenient. It might be a good thing that “setup closures" are a little bit ugly given that they are only able to “setup" mutable members and require those members to be initialized to potentially meaningless default values (or worse, IUO members defaulted to nil!).

Ideally an instance would be configured correctly when the initializer completes and we should work to find language solutions to make this safe and convenient. Once we have the right language solutions ideally we can use them in new types and retrofit existing types to use them over time, thus eliminating the need for “setup closures” alltogether.

···

On Dec 5, 2015, at 6: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

[Erica_Sadun]

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

[Vinicius_Vendramini]

While I understand the motivation behind this change, I think it’s pretty far from paying the addition of a new language feature. Is this

let questionLabel = UILabel() {
    $0.textAlignment = .Center
    $0.font = UIFont(name:"DnealianManuscript", size: 72)
    $0.text = currentQuestion.questionText
    $0.numberOfLines = 0
    view.addSubview($0)
}

really that much better than this?

let label = UILabel()

label.textAlignment = .Center
label.font = UIFont(name:"DnealianManuscript", size: 72)
label.text = currentQuestion.questionText
label.numberOfLines = 0
view.addSubview(label)

To be honest, the second looks much more readable to me. I like the indentation of the first one, but that doesn’t sound like enough of a reason: one could easily re-indent the lines to one’s liking (which actually looks kinda good with 4-spaces indentation, since `var` or `let` plus a space equals 4 characters:)

let label = UILabel()
    label.textAlignment = .Center
    label.font = UIFont(name:"DnealianManuscript", size: 72)
    label.text = currentQuestion.questionText
    label.numberOfLines = 0
    view.addSubview(label)

As far as I understand the proposals so far, this approach only changes the way we’d write the initialization, but doesn’t actually allow us to do something that couldn’t be done earlier (e.g. access internal members, change immutable variables…) right?

···

On Dec 5, 2015, at 11:31 PM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

As stated previously, I think a more specific solution is the best way to address the initialization / setup / configuration problem. While that is the case I did think some more about the ideas in this thread.

I believe two things are being proposed here:

1. The ability to append a trailing closure to any initializer (that doesn’t already declare one itself) that accepts a single argument of the initialized type. If the caller supplies such a closure, the compiler performs a code transformation as follows:

let questionLabel = UILabel() {
  $0.textAlignment = .Center
  $0.font = UIFont(name:"DnealianManuscript", size: 72)
  $0.numberOfLines = 0
}

becomes something like this (which is valid Swift today:

let questionLabel = UILabel(); {
  $0.textAlignment = .Center
  $0.font = UIFont(name:"DnealianManuscript", size: 72)
  $0.numberOfLines = 0
}(questionLabel)

The code transformation doesn’t actually buy us much. I’m a big believer in removing the need for clutter and boilerplate as much as possible, but even I must admit that the difference is really small and can be reduced a bit further using currently valid Swift code as demonstrated by the “configuration operator” mentioned in the previous post.

2. A new abbreviation of the $0 shorthand that would be valid only as the first characters on a line of code. For consistency this shorthand should work in any closure, not just in “setup closures”. I agree that $0 is uglier than necessary in this use case which would be relatively common in Cocoa code if this pattern becomes common.

The biggest drawback I can think of to a feature like this is that it is a feature specifically designed to make the use of var members more convenient. It might be a good thing that “setup closures" are a little bit ugly given that they are only able to “setup" mutable members and require those members to be initialized to potentially meaningless default values (or worse, IUO members defaulted to nil!).

Ideally an instance would be configured correctly when the initializer completes and we should work to find language solutions to make this safe and convenient. Once we have the right language solutions ideally we can use them in new types and retrofit existing types to use them over time, thus eliminating the need for “setup closures” alltogether.

On Dec 5, 2015, at 6: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

[DevAndArtist (Adrian Meister)]

I come across this topic and I instantly was overwhelmed by this idea of the Setup Closures. I build a little extension just to test it with UIKit. I thought adding this keyword for Setup Closures was a good idea. If we also could remove this in from the closure it would look good on my opinion.

protocol SettableType {
     
    init() // designated initializer
}

extension SettableType {
     
    init(@noescape setup: (this: Self) -> Void) {
         
        self.init()
        setup(this: self)
    }
}

extension UIView: SettableType {}

let view = UIView()

let questionLabel = UILabel() { this in /// <- REMOVE
     
    this.textAlignment = .Center
    this.font = UIFont(name:"SomeFontName", size: 72)
    this.text = "Hello World"
    this.numberOfLines = 0
    view.addSubview(this)
}

···

—
Regards Adrian

Am 6. Dezember 2015 bei 01:16:31, ilya via swift-evolution (swift-evolution@swift.org) schrieb:

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

[Jon_Hull]

I often do the following:

let questionLabel:UILabel = {
    let label = UILabel()
    label.textAlignment = .Center
    label.font = UIFont(name:"DnealianManuscript", size: 72)
    label.text = currentQuestion.questionText
    label.numberOfLines = 0
    view.addSubview(label)
    return label
}()

···

On Dec 6, 2015, at 3:59 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

let questionLabel = UILabel() .{
    ..textAlignment = .Center
    ..font = UIFont(name:"DnealianManuscript", size: 72)
    ..text = currentQuestion.questionText
    ..numberOfLines = 0
    view.addSubview($0)
}

Other thoughts?

[Erica_Sadun]

Matthew, I'll look for it and see what's there. More and more I'm thinking there are in fact two distinct problems to be solved: one that maintains self in a cascade of operations, and another that extends initializers, even for constants.

I'm hesitant to coalesce and summarize all this discussion yet because I'm already committed to championing the for-loop proposal but it seems that it would be really valuable right now to lay out the two side-by-side and discuss that plus your helpers-for-initializing-peroperties-of-same-name-as-parameters.

-- E
p.s. In my head, I'm thinking that the compiler must check in setup closures or self-specific-closures for potential overlaps between properties and existing symbols

···

On Dec 6, 2015, at 10:22 AM, Matthew Johnson <matthew@anandabits.com> wrote:

Hi Erica,

You might be interested in a possible language feature I described in the "helpers for initializing properties of same name as parameters" thread last night. It is intended to address the desire for concise, safe and flexible initialization without needing to sacrifice immutability. I would love to hear your thoughts on the list if you have a chance to read through it.

Thanks,
Matthew

Sent from my iPad

On Dec 6, 2015, at 11:10 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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

[anandabits (Matthew Johnson)]

I agree that this is pretty far from paying for a language feature. I much prefer the ideas we are discussing in the "helpers for initializing properties of same name as parameters" thread for reasons already stated.

···

Sent from my iPad

On Dec 6, 2015, at 10:36 AM, Vinicius Vendramini <vinivendra@gmail.com> wrote:

While I understand the motivation behind this change, I think it’s pretty far from paying the addition of a new language feature. Is this

let questionLabel = UILabel() {
    $0.textAlignment = .Center
    $0.font = UIFont(name:"DnealianManuscript", size: 72)
    $0.text = currentQuestion.questionText
    $0.numberOfLines = 0
    view.addSubview($0)
}

really that much better than this?

let label = UILabel()

label.textAlignment = .Center
label.font = UIFont(name:"DnealianManuscript", size: 72)
label.text = currentQuestion.questionText
label.numberOfLines = 0
view.addSubview(label)

To be honest, the second looks much more readable to me. I like the indentation of the first one, but that doesn’t sound like enough of a reason: one could easily re-indent the lines to one’s liking (which actually looks kinda good with 4-spaces indentation, since `var` or `let` plus a space equals 4 characters:)

let label = UILabel()
    label.textAlignment = .Center
    label.font = UIFont(name:"DnealianManuscript", size: 72)
    label.text = currentQuestion.questionText
    label.numberOfLines = 0
    view.addSubview(label)

As far as I understand the proposals so far, this approach only changes the way we’d write the initialization, but doesn’t actually allow us to do something that couldn’t be done earlier (e.g. access internal members, change immutable variables…) right?

On Dec 5, 2015, at 11:31 PM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

As stated previously, I think a more specific solution is the best way to address the initialization / setup / configuration problem. While that is the case I did think some more about the ideas in this thread.

I believe two things are being proposed here:

1. The ability to append a trailing closure to any initializer (that doesn’t already declare one itself) that accepts a single argument of the initialized type. If the caller supplies such a closure, the compiler performs a code transformation as follows:

let questionLabel = UILabel() {
  $0.textAlignment = .Center
  $0.font = UIFont(name:"DnealianManuscript", size: 72)
  $0.numberOfLines = 0
}

becomes something like this (which is valid Swift today:

let questionLabel = UILabel(); {
  $0.textAlignment = .Center
  $0.font = UIFont(name:"DnealianManuscript", size: 72)
  $0.numberOfLines = 0
}(questionLabel)

The code transformation doesn’t actually buy us much. I’m a big believer in removing the need for clutter and boilerplate as much as possible, but even I must admit that the difference is really small and can be reduced a bit further using currently valid Swift code as demonstrated by the “configuration operator” mentioned in the previous post.

2. A new abbreviation of the $0 shorthand that would be valid only as the first characters on a line of code. For consistency this shorthand should work in any closure, not just in “setup closures”. I agree that $0 is uglier than necessary in this use case which would be relatively common in Cocoa code if this pattern becomes common.

The biggest drawback I can think of to a feature like this is that it is a feature specifically designed to make the use of var members more convenient. It might be a good thing that “setup closures" are a little bit ugly given that they are only able to “setup" mutable members and require those members to be initialized to potentially meaningless default values (or worse, IUO members defaulted to nil!).

Ideally an instance would be configured correctly when the initializer completes and we should work to find language solutions to make this safe and convenient. Once we have the right language solutions ideally we can use them in new types and retrofit existing types to use them over time, thus eliminating the need for “setup closures” alltogether.

On Dec 5, 2015, at 6: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

[Erica_Sadun]

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

[Thorsten_Seitz]

Nice!
Actually I don’t mind the argument of the closure at all and would probably just name it after the class, i.e. „label“ in the example:

let questionLabel = UILabel() { label in
     
    label.textAlignment = .Center
    label.font = UIFont(name:"SomeFontName", size: 72)
    label.text = "Hello World"
    label.numberOfLines = 0
    view.addSubview(label)
}

-Thorsten

···

Am 06.12.2015 um 12:59 schrieb Adrian Zubarev via swift-evolution <swift-evolution@swift.org>:

let questionLabel = UILabel() { this in /// <- REMOVE
     
    this.textAlignment = .Center
    this.font = UIFont(name:"SomeFontName", size: 72)
    this.text = "Hello World"
    this.numberOfLines = 0
    view.addSubview(this)
}

[anandabits (Matthew Johnson)]

Thanks Erica. I agree that there are two distinct, but related problems being discussed here as well as several ideas for solutions.

I will try to provide a side-by-side summary of the problems and proposed solutions in the next day or so when I have a chance to pull it together.

···

On Dec 6, 2015, at 11:26 AM, Erica Sadun <erica@ericasadun.com> wrote:

Matthew, I'll look for it and see what's there. More and more I'm thinking there are in fact two distinct problems to be solved: one that maintains self in a cascade of operations, and another that extends initializers, even for constants.

I'm hesitant to coalesce and summarize all this discussion yet because I'm already committed to championing the for-loop proposal but it seems that it would be really valuable right now to lay out the two side-by-side and discuss that plus your helpers-for-initializing-peroperties-of-same-name-as-parameters.

-- E
p.s. In my head, I'm thinking that the compiler must check in setup closures or self-specific-closures for potential overlaps between properties and existing symbols

On Dec 6, 2015, at 10:22 AM, Matthew Johnson <matthew@anandabits.com <mailto:matthew@anandabits.com>> wrote:

Hi Erica,

You might be interested in a possible language feature I described in the "helpers for initializing properties of same name as parameters" thread last night. It is intended to address the desire for concise, safe and flexible initialization without needing to sacrifice immutability. I would love to hear your thoughts on the list if you have a chance to read through it.

Thanks,
Matthew

Sent from my iPad

On Dec 6, 2015, at 11:10 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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

[Erica_Sadun]

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

https://gist.github.com/erica/eb32feb22ba99629285a

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

[ilya]

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 (
Speeding up Swift playgrounds with closure initialization #swiftlang — Erica Sadun
).

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

[jtbandes (Jacob Bandes-Storch)]

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 (
Speeding up Swift playgrounds with closure initialization #swiftlang — Erica Sadun
).

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

[dwaite (David Waite)]

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

[Erica_Sadun]

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

[Erica_Sadun]

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

[anandabits (Matthew Johnson)]

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

[anandabits (Matthew Johnson)]

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

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

[dwaite (David Waite)]

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 <mailto: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