[swift-evolution] Two thoughts on concurrency

Sat Aug 26 16:31:44 CDT 2017

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 <swift-evolution at swift.org> wrote:
> 
> 
>> On Aug 24, 2017, at 9:17 PM, Félix Cloutier <felixcloutier at icloud.com <mailto:felixcloutier at icloud.com>> 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 <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> a écrit :
>>> 
>>> 
>>>> On Aug 24, 2017, at 8:57 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> 
>>>> On Aug 24, 2017, at 1:59 PM, Dave DeLong via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170826/76132b20/attachment.html>