I don’t think that there are any simple rules that define “Complexity”. I hope that is not too off-topic...
<An aside: 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. 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: https://www.edwardtufte.com/tufte/books_vdqi > 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). 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. 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. 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. > On Aug 24, 2017, at 10:29 PM, Chris Lattner via swift-evolution > <[email protected]> wrote: > > >> On Aug 24, 2017, at 9:17 PM, Félix Cloutier <[email protected] >> <mailto:[email protected]>> wrote: >> >> 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. > > 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. > > 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. > > -Chris > > > > >> Félix >> >>> Le 24 août 2017 à 20:58, Chris Lattner via swift-evolution >>> <[email protected] <mailto:[email protected]>> a écrit : >>> >>> >>>> On Aug 24, 2017, at 8:57 PM, Chris Lattner via swift-evolution >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> >>>> On Aug 24, 2017, at 1:59 PM, Dave DeLong via swift-evolution >>>> <[email protected] <mailto:[email protected]>> wrote: >>>>> Keyword Explosion >>>>> >>>>> 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 anti-pattern. 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 >>>>> async/await, but there’s also been discussion of actor, reliable, >>>>> distributed, behavior, message, and signal (and I’ve probably missed >>>>> others). >>>> >>>> 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. >>> >>> Concrete example, this is (weird but) valid code: >>> >>> var weak = 42 >>> weak += 2 >>> print(weak+weak) >>> >>> >>> This is a consequence of weak not being a keyword. >>> >>> -Chris >>> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
