[swift-evolution] Request for Discussion: Setup closures

[Sean Heber]

Yeah, that thought occurred to me as I was writing it out. One possibility would be to limit what can go inside that block - perhaps all statements must be functions called on the value you are using in the with block? Or perhaps simply prefix them with a period? (Maybe looks too much like enum?)

with let task = NSTask() {
 .launchPath = path
 .arguments = []
 .standardOutput = pipe
}

etc. 

l8r
Sean

> On Dec 4, 2015, at 3:51 PM, Michel Fortin <michel.fortin at michelf.ca> wrote:
> 
> Le 4 déc. 2015 à 16:35, Sean Heber <sean at fifthace.com> a écrit :
> 
>> I would also be in favor of something more generally applicable rather than making initialization more special. I think I prefer the block-style over Dart’s approach. Smalltalk uses semicolons for this, if I recall. I’m not sure I like using a special operator. I’m obviously a keyword guy.. :P
>> 
>> with let task = NSTask() {
>>  launchPath = "/usr/bin/mdfind"
>>  arguments = ["kMDItemDisplayName == *.playground"]
>>  standardOutput = pipe
>> }
>> 
>> Also valid:
>> 
>> with someVariable {
>>  func1()
>>  func2(“etc")
>> }
>> 
>> Which would call func1() and func2() on the someVariable instance (which I think would be quite expected).
> 
> The problem with this approach is that it can become ambiguous with the outer scope pretty easily, if not to the compiler at least for the reader:
> 
> 	let launchPath = "a.out"
> 	let description = "blah blah"
> 	with let task = NSTask() {
> 		launchPath = launchPath // eh, what?
> 		arguments = [launchPath, description] // is that task.description?
> 	}
> 
> I think it's important that things referring to the "task" in the above example be syntactically distinguishable.
> 
> It can also lead to code breakage:
> 
> 	let path = "a.out"
> 	with let task = NSTask() {
> 		launchPath = path
> 	}
> 
> That would work fine one day, but what if in the next OS release NSTask gets a new "path" property? That code breaks silently once you recompile with the newer SDK.
> 	
> 
> -- 
> Michel Fortin
> michel.fortin at michelf.ca
> https://michelf.ca
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution