[swift-evolution] Customized Inline Init Closure

[Weston Catron]

I believe you’re referring to this https://gist.github.com/erica/eb32feb22ba99629285a <https://gist.github.com/erica/eb32feb22ba99629285a> currently being developed. I was initially limiting this proposal to initializers, specifically overriding them verses immediately following them. This is an important distinction because it would require required properties, verses the initializers still taking care of this. This doesn’t make it in opposition to method cascading, it might possibly be a nice addition. It also appears like self is not maintained (in that method cascading proposal anyhow), self is just not required unless variables names overlap. Below is my exercise in keeping self.

Perhaps this alternative would work: 

class Foo {
    var name:String
    
    init (name:String) {
        self.name = name
    }
}

class Fee {
    var name:String = "Fee-fi"
    static func createFoo (name:String) -> Foo {
        let foo = Foo {
            foo.name = self.name + "-" + name
        }
        return foo;
    }
}

let name = "fo-fum"

let other = Fee.createFoo(name);
print(other.name) // "Fee-fi-fo-fum"

let another = Foo {
    // name = self.name // Ambiguous, self isn't defined.
    // self.name = name // Simplist, but isn't clear within scopes that contain self (like class functions) It would require a common javascript work around for this, saving a `that = this;` before the closure.
    another.name = name // Clear, another is only required when names overlap in scope.
    // print((self == nil)) // true
}

This has restrictions. An initializer can’t be used directly within a return for example:

class Fee {
    var name:String = "Fee-fi"
    static func createFoo (name:String) -> Foo {
        return Foo {
            return.name = self.name + "-" + name
        }
    }
}

That is admittedly awkward, bad form, but not technically wrong.

Unless there is a better alternative, keeping self the same inside the closure as outside seems difficult to do, but not impossible.

-Weston

> On Jan 3, 2016, at 7:39 AM, Tino Heth <2th at gmx.de> wrote:
> 
> Something similar has been discussed ("method cascading"), and I hope the feature will be considered for Swift 4(?).
> It is a little bit different, though:
> "self" would not change its meaning (which imho is a plus), and the syntax is different.
> 
> Tino

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160104/fbefa7cd/attachment.html>