<div dir="ltr">If you were writing a book, would you want to put every paragraph into a separate file?<br><br><div class="gmail_quote"><div dir="ltr">On Mon, Dec 14, 2015 at 2:49 AM ilya via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">> I believe that *most*—certainly not all, but most—uses of `local` are like this. `local` would improve the code's safety, but some sort of refactoring would be even better. Because of that, I don’t think `local` is as valuable as you think it is.<div><br></div></div><div dir="ltr"><div>+1.</div><div><br></div><div>Let's try to promote existing access mechanisms, such as separating code into a number of files, first, before deciding that we need new keywords.</div></div><div dir="ltr"><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 14, 2015 at 4:53 AM, Brent Royal-Gordon via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>>> But it’s not zero-cost. It’s another thing to learn, another thing to think about, another way you have to mentally analyze your code.<br>
><br>
> I meant zero performance cost. Of course all features have "cost" if we mean "cognitive overhead". Type safety for example has a huge cognitive overhead. Think back to the days of "Bool is not an NSString". But the benefit of typesafety is large.<br>
><br>
> In this case, the cognitive overhead is small, and so is the benefit. But I think the value-per-unit-cost is similar. In both cases the compiler helps you not do something very very bad, that is hard to debug in ObjC.<br>
<br>
</span>And I’m saying that I think the benefit is even smaller than you think it is, because you can usually get the same benefits by other means, and the resulting code will be *even safer* than `local` would give you. Again, consider the “value protected by a queue” case. Using `local` here limits the amount of code which could contain an access-without-synchronization bug, but `Synchronized` *completely eliminates* that class of bugs. Synchronized is a *better*, *safer* solution than `local`.<br>
<br>
I believe that *most*—certainly not all, but most—uses of `local` are like this. `local` would improve the code's safety, but some sort of refactoring would be even better. Because of that, I don’t think `local` is as valuable as you think it is.<br>
<span><br>
>> many people, when they do that, find this idea wanting.<br>
><br>
> Who? You? Then build an argument around that. I don't know who "many people" are or what their justification is.<br>
<br>
</span>I’m sorry, I don’t mean to make it sound like I’m speaking for some big, ill-defined posse. I just mean that different people will draw the line on the necessary cost-to-benefit in different places, and for some, this feature will fall on the wrong side of the line. People who don’t like this feature don’t misunderstand it; they just have a different subjective assessment of its value.<br>
<span><br>
> My justification is essentially that A) something like Synchronized is a problem nearly everybody has and B) the difficulty of defining a class-based solution in an optimal way.<br>
><br>
> On B, we seem to agree:<br>
><br>
>> it might be difficult to construct a Synchronized instance correctly.<br>
><br>
> So I can only conclude you disagree about A. However, I think my A is much stronger than is strictly necessary to demand a language feature. There are plenty of language features that not everyone uses, so the fact that you don't have a need for it (or even "many people") is not really a counterargument I am able to understand.<br>
<br>
</span>As far as a standard Synchronized is concerned, I agree with you that it’s a good idea. I am simply *worried* that we may have trouble coming up with a design that’s flexible enough to accommodate multiple synchronization methods, but still makes it easy to create a properly-configured Synchronized object. For example, something like this would be so complicated to configure that it would virtually defeat the purpose of having a Synchronized type:<br>
<br>
class Synchronized<Value> {<br>
init(value: Value, mutableRunner: (Void -> Void) -> Void, immutableRunner: (Void -> Void) -> Void) { … }<br>
…<br>
}<br>
<br>
So I’m going to think out loud about this for a minute. All code was written in Mail.app and is untested.<br>
<br>
I suppose we start with a protocol. The ideal interface for Synchronized would look something like this:<br>
<br>
protocol SynchronizedType: class {<br>
typealias Value<br>
func withMutableValue<R>(mutator: (inout Value) throws -> R) rethrows -> R<br>
func withValue<R>(accessor: Value throws -> R) rethrows -> R<br>
}<br>
<br>
You could obviously write separate types like:<br>
<br>
class QueueSynchronized<Value>: SynchronizedType {<br>
private var value: Value<br>
private let queue: dispatch_queue_t<br>
<br>
init(value: Value, queue: dispatch_queue_t = dispatch_queue_create(“QueueSynchronized”, DISPATCH_QUEUE_CONCURRENT)) {<br>
self.value = value<br>
self.queue = queue<br>
}<br>
<br>
func withMutableValue<R>(@noescape mutator: (inout Value) throws -> R) rethrows -> R {<br>
var ret: R?<br>
var blockError: NSError?<br>
dispatch_barrier_sync(queue) {<br>
do {<br>
ret = try mutator(&value)<br>
}<br>
catch {<br>
blockError = error<br>
}<br>
}<br>
if let error = blockError {<br>
throw error<br>
}<br>
return ret!<br>
}<br>
<br>
func withValue<R>(@noescape accessor: Value throws -> R) rethrows -> R {<br>
var ret: R?<br>
var blockError: NSError?<br>
dispatch_sync(queue) {<br>
do {<br>
ret = try accessor(value)<br>
}<br>
catch {<br>
blockError = error<br>
}<br>
}<br>
if let error = blockError {<br>
throw error<br>
}<br>
return ret!<br>
}<br>
}<br>
<br>
and:<br>
<br>
class NSLockSynchronized<Value>: SynchronizedType {<br>
private var value: Value<br>
private var lock: NSLock<br>
<br>
init(value: Value, lock: NSLock = NSLock()) {<br>
self.value = value<br>
self.lock = lock<br>
}<br>
<br>
func withMutableValue<R>(@noescape mutator: (inout Value) throws -> R) rethrows -> R {<br>
lock.lock()<br>
defer { lock.unlock() }<br>
<br>
return try mutator(&value)<br>
}<br>
<br>
func withValue<R>(@noescape accessor: Value throws -> R) rethrows -> R {<br>
// XXX I don’t know how to get concurrent reads with Cocoa locks.<br>
lock.lock()<br>
defer { lock.unlock() }<br>
<br>
return try accessor(value)<br>
}<br>
}<br>
<br>
But that’s not a very satisfying design—so much boilerplate. Maybe we make the thing you’re synchronizing *on* be the protocol?<br>
<br>
protocol SynchronizerType: class {<br>
func synchronizeForReading(@noescape accessor: Void -> Void)<br>
func synchronizeForWriting(@noescape mutator: Void -> Void)<br>
}<br>
<br>
final class Synchronized<Value> {<br>
private var value = Value<br>
private let synchronizer: SynchronizerType<br>
<br>
init(value: Value, on synchronizer: SynchronizerType) {<br>
self.value = value<br>
self.synchronizer = synchronizer<br>
}<br>
<br>
func withMutableValue<R>(@noescape mutator: (inout Value) throws -> R) rethrows -> R {<br>
var ret: R?<br>
var blockError: NSError?<br>
synchronizer.synchronizeForWriting {<br>
do {<br>
ret = try mutator(&value)<br>
}<br>
catch {<br>
blockError = error<br>
}<br>
}<br>
if let error = blockError {<br>
throw error<br>
}<br>
return ret!<br>
}<br>
<br>
func withValue<R>(@noescape accessor: Value throws -> R) rethrows -> R {<br>
var ret: R?<br>
var blockError: NSError?<br>
synchronizer.synchronizeForReading {<br>
do {<br>
ret = try accessor(value)<br>
}<br>
catch {<br>
blockError = error<br>
}<br>
}<br>
if let error = blockError {<br>
throw error<br>
}<br>
return ret!<br>
}<br>
}<br>
<br>
extension dispatch_queue: SynchronizerType {<br>
func synchronizeForReading(@noescape accessor: Void -> Void) {<br>
dispatch_sync(self, accessor)<br>
}<br>
<br>
func synchronizeForWriting(@noescape mutator: Void -> Void) {<br>
dispatch_barrier_sync(self, mutator)<br>
}<br>
}<br>
<br>
extension NSLock: SynchronizerType {<br>
func synchronizeForReading(@noescape accessor: Void -> Void) {<br>
// XXX I don’t know how to get concurrent reads with Cocoa locks.<br>
lock()<br>
accessor()<br>
unlock()<br>
}<br>
<br>
func synchronizeForWriting(@noescape mutator: Void -> Void) {<br>
lock()<br>
mutator()<br>
unlock()<br>
}<br>
}<br>
<br>
Huh. That’s…actually pretty clean. And I suppose if you want it to default to using a dispatch queue, that’s just a default value on Synchronized.init(value:on:), or a new init(value:) added in an extension in LibDispatch. I thought this would be a lot hairier.<br>
<br>
So, yeah, I guess I like the idea of a standard Synchronized. A well-designed version (one with something like SynchronizerType) can work with multiple locking mechanisms, without resorting to something error-prone like passing in closures. +1 for that.<br>
<div><div><br>
--<br>
Brent Royal-Gordon<br>
Architechies<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div></div></div><div dir="ltr"><div></div></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=JoVvr1nwtkf-2FcycRIsh0Ekp6hrdbCH7iUjVG-2FENQSudOE58NGv1rWW8ZbUkqhLHzTkO5aBPvTTt2lm2ERh0cRSlbqojtrjvw0QpQWpbPW1e4bOUd2RgLo9gtMoO9krHtRtcZZEB1qXLs-2F4Ox3K46O2w9GKtx9WTfspUyz-2FeP5R3c-2Fb3gcEouimik90-2B9iSfxMfJAcBYNhz0jpujDWul-2FcqNa1ba9fhY1IF2e6nuQmtM-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important">
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div></div>