> 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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
