> As a plus, it makes code easier to write, sometimes; or at least it seems so. > On the other hand, I think it makes code harder to comprehend. A `with` > statement introduces a new scope in which it is not obvious what exactly > happens. For example: > > with(someObject) { > foo() > } > > what does it do? The mere fact that I wrote `with(someObject)` suggests that > `someObject.foo()` is what should happen. But it could also mean `self.foo()` > or just the global function `foo()`.
I support having two separate, but interlocking, features: * A `with(_:user:)` function in the standard library which can access, and perhaps modify, a value. * The ability to name a closure parameter `self`, which would make bare method calls be directed to that parameter. So if your code said: with(someBarObject) { self in ... foo() ... bar() ... bar() ... foo() } Then the foo() and bar() calls would definitely be either on someBarObject, or to global functions, whereas if you said: with(someBarObject) { value in ... foo() ... bar() ... bar() ... foo() } Then they would definitely be on either the closed-over `self`, or to global functions. (In no case, however, should it be possible that a call could refer to any of the three.) -- Brent Royal-Gordon Architechies _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution