For what it's worth, I left vba behind a long time ago and I have some bad memories of what I saw in these with blocks: people writing a page worth of code where only a couple line were actually referencing .xxxxx. In the end, they thought it made their code look cool when I just saw it as a readability nightmare. IMHO a good language is a mix between coolness and restraint, such that the worse things the worst programmers will do cannot FAR outweigh the good the fewer disciplined programmers will write. Leaving this feature in the realm of libraries will mandate that teams discuss the topic, and choose the pattern they want to buy into. Putting it into the language will IMHO result in a lot more anything-goes, on account of "well it was there, so they want us to use it, right?!"
Cheers (From mobile) > On Apr 14, 2016, at 3:49 PM, Vladimir.S via swift-evolution > <[email protected]> wrote: > > Agree, that we can already use some hacks(IMO) to have some kind of what we > need. > Actually, we already discussed some variants : method "with" in extension to > type and global generic function "with". Each of them has disadvantages in > compare to "with" language construction. In your example you need to create > temp instance, need "return", calls the block() - many noise for simple > action. > > Also, such workarounds not always protect us from problems(like modifying > constant struct instance in generic "with" method - it compiles. but raise > runtime error) and each of us needs to move these workarounds from project to > project, plus we use different implementation for the "with" feature, no > standard, in one project with many developers we'll find different variants > for the same "with" feature. > > I believe we need such language construction in some or another > implementation. > > I suggest these constructions: > > // similar to "if let.. " and "guard let.." > with let questionLabel = UILabel() { > //... > } > > with var some = SomeStruct() { > //... > } > > with questionLabel { > // .. > } > > And suggest to discuss these variants: > > "one-point" (my preffered) : > > with questionLabel { > .textAlignment = .Center > .font = UIFont(name:"DnealianManuscript", size: 72) > .text = "?" > .numberOfLines = 0 > } > > "two points": > > with questionLabel { > ..textAlignment = .Center > ..font = UIFont(name:"DnealianManuscript", size: 72) > ..text = "?" > ..numberOfLines = 0 > } > > "$" sign : > > with questionLabel { > $.textAlignment = .Center > $.font = UIFont(name:"DnealianManuscript", size: 72) > $.text = "?" > $.numberOfLines = 0 > } > > "$0" (don't think this is good, as there can not be $1 etc): > > with questionLabel { > $0.textAlignment = .Center > $0.font = UIFont(name:"DnealianManuscript", size: 72) > $0.text = "?" > $0.numberOfLines = 0 > } > > Opinions? > > On 14.04.2016 13:41, Milos Rankovic via swift-evolution wrote: >>> On 13 Apr 2016, at 17:04, Erica Sadun via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> The biggest advantage of thewithpattern IMO is Cocoa initializers. It >>> provides a more unified >>> initialization scope. Instead of: >>> >>> letquestionLabel =UILabel() >>> questionLabel.textAlignment= .Center >>> questionLabel.font= UIFont(name:"DnealianManuscript", size:72) >>> questionLabel.text=currentQuestion.text >>> questionLabel.numberOfLines=0 >> >> Whilst I would not mind the `with` pattern, it’s worth noting that Swift >> already has some very fine alternatives: >> >> letquestionLabel: UILabel= { >> let$ = UILabel() >> $.textAlignment= .Center >> $.font= UIFont(name:"DnealianManuscript", size: 72) >> $.text= "?" >> $.numberOfLines= 0 >> return$ >> }() >> >> >> Including some lazy options: >> >> >> private(set)lazyvarquestionLabel: UILabel= {...}() >> >> >> staticletquestionLabel: UILabel= {...}() >> >> milos >> >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
