> On Dec 3, 2017, at 1:26 PM, Chris Lattner via swift-evolution 
> <swift-evolution@swift.org> wrote:
> On Dec 3, 2017, at 11:03 AM, Magnus Ahltorp <m...@kth.se> wrote:
>>> 4 Dec. 2017 02:40 Chris Lattner via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> That’s a good principle.  However, a dynamic member lookup is just a member 
>>> lookup.  By that principle, it should look like a member lookup :-)
>>> Further, I incorporated some of the conversation with Matthew into the 
>>> proposal, showing how adding even a single sigil to dynamic member lookup 
>>> to distinguish it is problematic:
>>> https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438#increasing-visibility-of-dynamic-member-lookups
>>> Further, adding something like .dynamic would completely undermind the 
>>> proposal.  You can already write:
>>>     x.get(“foo”).get(“bar”)
>>> having to write:
>>>     x.dynamic.foo.dynamic.bar
>>> has no point.
>> This example shows what many on this list don't believe: that any Swift 
>> method or member access can fail. If the return value of this "get" method 
>> is an IUO, or not an Optional at all, and doesn't throw, then the expression 
>> would have to fail hard if "foo" didn't resolve to something meaningful.
>> The most common argument against this proposal is that someone could make an 
>> API using Dynamic Member Lookup that could fail even though it is not 
>> apparent to the caller. But, as we see in the example, this is just as 
>> possible today.
> Correct.  The argument also fails to recognize that (when bridging to a 
> dynamic language):
>       x+y
> Is a completely dynamic method call which can fail (or return IUO), as is:
>       x[i]
> And that this is true with no changes to Swift.  The claim that such a thing 
> is counter to the design of Swift is completely perplexing to me.

Chris, having myself nursed this sense that Swift is somehow “especially safe” 
in a way that feels closer to ML than C, you’ve prompted me to consider _why_ I 
feel that way.

Sentiments like this subjectively fit the _experience_ of using Swift. When 
using the language in practice, it’s fairly clear to a mindful developer which 
operations carry some inherent level of danger, what kind of danger that is, 
how to reason about it, and how to mitigate it. (Usually, anyway.)

Having all had this pleasant experience, I think we may be too quick to look 
for the explanation in the design of the language itself. We fail to notice 
that it comes not from the language alone, but from the whole ecosystem that 
surrounds it: standard library design, naming conventions, tools, libraries, 
culture, Erica’s books, etc.

Optionals present themselves as a specially privileged part of the language; 
`withUnsafeBytes` presents itself as a library call using existing language 
features. But both share a similar definitively Swift-ish aesthetic in how they 
guide our attention, and how they circumscribe programmer error while leaving 
the language ergonomic and situationally adaptable.

Your reminder is a good one: Swift already does not have, and never has had, a 
sense of safety that depends on Haskell-like strictness in the language itself. 
The design question at hand in this thread thus becomes not “how can we prevent 
dynamic dispatch from ruining everything” but rather “how can we introduce this 
new element in a way that does not disrupt the ecosystem.” In considering that, 
we’d do well to remember the long-established language features that have so 
far failed to ruin everything despite their impurity.

• • •

On this thread, there’s a lot of the tired old reflexive sneering at dynamic 
languages — I’ll spare my thoughts on that here — and a fear that creeping 
dynamism will ruin the whole neighborhood and destroy all we hold dear. I don’t 
think that will happen. I see Chris’s other examples, and the line of thought 
above, as an optimistic answer to that fear: Swift’s Swiftiness has _always_ 
depended on good judgement. It has always depended on an ecosystem that extends 
beyond the language features, and in some particular cases even pushes toward 
mindfulness and safety _in spite of_ language features. A language feature 
alone will not erase the good sense of the language’s stewards, or poison its 

I think — incurring universal flaming in this discussion, I’m sure — there is a 
place for dynamic dispatch in Swift. There are a few problems, like the Python 
interop, where it is the right answer. And I’m sure that the ecosystem can 
integrate it in a way that does not fundamentally alter what we like about 
Swift. This is a language that’s managed to integrate **raw memory access**, 
for heaven’s sake, and still “feel closer to ML than C!” If it can do that, it 
can certainly withstand the far smaller disturbance in the force of what Chris 
is proposing here.



swift-evolution mailing list

Reply via email to