<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">On Aug 24, 2017, at 1:59 PM, Dave DeLong via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><div><blockquote type="cite" class=""><b class="">Keyword Explosion</b><br class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><br class=""></div></div><div class="">During the Great Access Control Wars of Swift 4, one of the points that kept coming up was the reluctance to introduce a bazillion new keywords to address all the cases that were being brought up. The impression I got is that adding new keywords was essentially an <i class="">anti-pattern</i>. And so when I’m reading through this onslaught of emails, I’m troubled by how everything is seeming to require new keywords. There’s the obvious <font face="Menlo" class=""><span style="font-size: 11px;" class="">async</span></font>/<font face="Menlo" class=""><span style="font-size: 11px;" class="">await</span></font>, but there’s also been discussion of <font face="Menlo" class=""><span style="font-size: 11px;" class="">actor</span></font>, <font face="Menlo" class=""><span style="font-size: 11px;" class="">reliable</span></font>, <font face="Menlo" class=""><span style="font-size: 11px;" class="">distributed</span></font>, <font face="Menlo" class=""><span style="font-size: 11px;" class="">behavior</span></font>, <font face="Menlo" class=""><span style="font-size: 11px;" class="">message</span></font>, and <font face="Menlo" class=""><span style="font-size: 11px;" class="">signal</span></font> (and I’ve probably missed others).</div></div></div></blockquote><div><br class=""></div><div>I can’t speak for message/signal, but you need to understand a bit more about how Swift works. There is a distinction between an actual keyword (which ‘async’ would be, and ‘class’ currently is) and “modifiers”. Modifiers occur with attributes ahead of a real keyword, but they are not themselves keywords. They are things like weak, mutating, reliable, distributed, etc. If we go with the “actor class” and “actor func” approach, then actor would not be a keyword.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I’m not opposed to adding new keywords by any means, but can we get some clarification on some limits of reasonableness? What restraint (if any) should we be exercising as we consider this feature?</div></div></div></blockquote><div><br class=""></div><div>There is no general rule that can be applied. Details matter.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><b class="">Language vs Library Feature</b></div><div class=""><b class=""><br class=""></b></div><div class="">Related to the explosion of keywords is the question of whether the concurrency model is going to be a language feature or a library feature. Allow me to explain…</div><div class=""><br class=""></div><div class="">We currently have <i class="">language</i> support for errors with <font face="Menlo" class=""><span style="font-size: 11px;" class="">throws</span></font> and <font face="Menlo" class=""><span style="font-size: 11px;" class="">try</span></font> (and friends):</div><div class=""><br class=""></div><div class=""><font face="Menlo" class=""><span style="font-size: 11px;" class="">func doSomething() throws → Value { … }</span></font></div><div class=""><font face="Menlo" class=""><span style="font-size: 11px;" class=""><br class=""></span></font></div><div class=""><font face="Menlo" class=""><span style="font-size: 11px;" class="">let value = try doSomething()</span></font></div><div class=""><br class=""></div><div class="">However, this could be viewed as sugar syntax for a hypothetical <i class="">library</i> feature involving a <font face="Menlo" class=""><span style="font-size: 11px;" class="">Result<T, Error></span></font> type:</div><div class=""><br class=""></div><div class=""><font face="Menlo" class=""><span style="font-size: 11px;" class="">func doSomething() → Result<Value, Error> { … }</span></font></div><div class=""><font face="Menlo" class=""><span style="font-size: 11px;" class=""><br class=""></span></font></div><div class=""><font face="Menlo" class=""><span style="font-size: 11px;" class="">let value = doSomething().value! // or however you get the value of a Result</span></font></div><div class=""><br class=""></div><div class="">In other words, <font face="Menlo" class=""><span style="font-size: 11px;" class="">throws</span></font> and <font face="Menlo" class=""><span style="font-size: 11px;" class="">try</span></font> are the language support for silently hiding a <font face="Menlo" class=""><span style="font-size: 11px;" class="">Result<T, Error></span></font> type.</div></div></div></blockquote><div><br class=""></div><div>Sort of, but I see what you’re saying.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I would be <i class="">really</i> happy if whatever concurrency model we end up with ends up being sugar syntax for a library feature, such that <font face="Menlo" class=""><span style="font-size: 11px;" class="">async</span></font> and <font face="Menlo" class=""><span style="font-size: 11px;" class="">await</span></font> (or whatever we decide on) become sugar for dealing with a <font face="Menlo" class=""><span style="font-size: 11px;" class="">Future<T></span></font> type or whatever. Implementing concurrency in this manner would free app developers to handle concurrency in the manner in which they’re familiar. If you wanted, you call the function without <font face="Menlo" class=""><span style="font-size: 11px;" class="">await</span></font> and get back the underlying <font face="Menlo" class=""><span style="font-size: 11px;" class="">Future<T></span></font>. a<font face="Menlo" class=""><span style="font-size: 11px;" class="">sync</span></font> becomes sugar for simplifying the return type, like in the <font face="Menlo" class=""><span style="font-size: 11px;" class="">throws</span></font> example above. <font face="Menlo" class=""><span style="font-size: 11px;" class="">try await</span></font> becomes sugar for fulfilling the promise or dealing with a cancellation (or other) error, etc.</div></div></div></blockquote><div><br class=""></div><div>I understand the conceptual ideal of something being "pure sugar”, but that it is also limiting. The design as proposed is exactly the opposite of what you suggest: since there are many interesting user facing libraries (future is just one of them) that can be built on top of the primitive language features.</div><div><br class=""></div><div>You can still think of the primitives as being built in terms of futures if that makes sense to you, but it isn’t any more correct than it is to say that throws is implemented in terms of a hidden result type.</div><div><br class=""></div><div>-Chris</div><div><br class=""></div></div><br class=""></body></html>