<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=""><div class="">I don’t think that there are any simple rules that define “Complexity”. I hope that is not too off-topic...</div><div class=""><br class=""></div><div class=""><An aside:</div><div class="">Whenever anyone tells me that a UI must only have 6 (or some other arbitrary number) of elements, because of some limits on short term memory or some such, I always bring-up the fact that even simple maps (the physical things) can have thousands of names and symbols and most people (admittedly after some training as children) use them without too much effort. Of, course source files are similarly complex (well, at least iOS view controllers :). On the flip side, just a few poorly chosen options in a UI can make it incomprehensible to most users.</div><div class=""><br class=""></div><div class="">In short, presenting complex information is as much art as science. These books used to be very popular and are a great illustration of this: <a href="https://www.edwardtufte.com/tufte/books_vdqi" class="">https://www.edwardtufte.com/tufte/books_vdqi</a></div><div class="">></div><div class=""><br class=""></div><div class="">It makes sense to make a distinction between adding keywords/modifiers to implement a niche feature and implementing fairly well established abstractions like "async/await" and “actor”. There should be a lower bar to using well established terms if the implementation is faithful to standard (and “modern”) usage. Swift does not exist in isolation, but in world where developers commonly use multiple languages. The notion of progressive disclosure is mentioned as being very important to the design to Swift and a lot of code can be written in Swift without ever needing to see "async/await”, so it this feature "meets the standard" for progressive disclosure (which probably can be more formally defined).</div><div class=""><br class=""></div><div class="">There should be a very high bar to adding keywords to support special cases and using common terms in non-standard ways. Of course, there will always be some differences in the exact usage of a term in different languages.</div><div class=""><br class=""></div><div class="">It might make sense to create a manifesto-like document of guidelines for evolving Swift that would serve as a first test or filter on proposals. The danger of creating such a document is that great proposals might fail the test “on paper” and be effectively killed.</div><div class=""><br class=""></div><div class=""><div class="">A small nit: Swift exceptions are (thankfully) kind-of sugar for : `Result<T>` not `Result<T, Error>` meaning that Error is a protocol, not a generic parameter in Swift standard usage. As I have mentioned (to often already, probably) that I believe that whatever benefit `Result<T, Error>` brings is not worth the hassle and mismatch with Swift's standard usage of errors. </div><div class=""><br class=""></div></div><div><blockquote type="cite" class=""><div class="">On Aug 24, 2017, at 10:29 PM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Aug 24, 2017, at 9:17 PM, Félix Cloutier <<a href="mailto:felixcloutier@icloud.com" class="">felixcloutier@icloud.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I feel that it's important to point out that this example feels weird because even though the compiler doesn't treat "weak" as a reserved term, most developers perceive it as one. I don't think that David is worried that we're taking away all the cool words from the realm of identifiers; the problem is that "technically not a keyword" is a qualifier mostly distinct from "not perceived as a keyword". Even if attributes don't live in the same token namespace as identifiers as far as the compiler is perceived, I'd argue that they add about the same complexity (or more) to the mental model that developers have to have about the language.</div></div></div></blockquote><div class=""><br class=""></div>Obviously details matter here, but there is an important time and place to introduce a “conceptual” keyword: it is when there is an important and distinct concept that needs to be thought about by the humans that interact with the code.</div><div class=""><br class=""></div><div class="">In the proposal “actor” vs “distributed actor” is one of those really important distinctions, which is why (IMO) it deserves the “complexity” of a new identifier. It isn’t the identifier that adds the complexity, it is the expansion of the language surface that the identifier designates.</div><div class=""><br class=""></div><div class="">-Chris</div><div class=""><br class=""><div class=""><br class=""></div><div class=""><br class=""></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="">Félix</div><br class=""><div class=""><blockquote type="cite" class=""><div class="">Le 24 août 2017 à 20:58, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Aug 24, 2017, at 8:57 PM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div 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 class=""><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 class=""><br class=""></div><div class="">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></div></div></blockquote><br class=""></div><div class="">Concrete example, this is (weird but) valid code:</div><div class=""><br class=""></div><div class="">var weak = 42</div><div class="">weak += 2</div><div class="">print(weak+weak)</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">This is a consequence of weak not being a keyword.</div><div class=""><br class=""></div><div class="">-Chris</div><div class=""><br class=""></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>