[swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

[Joe DeCapo]

+1 to Paul's comments

Many of the concerns about typos causing runtime bugs scream out to me, "I want to write code that is completely untested and only validated by the compiler". But this is just as bad for a strong, statically typed language as it is for a weak, dynamically typed language (and honestly, in my experience, dynamic language communities seem to be way better about writing tests due to the fact that statically typed communities tend to rely way more on the compiler). At the very least, I would expect a programmer to run a happy path to make sure the code they wrote actually works. And if they don't, and it isn't then caught by QA, then there are much larger issues at hand than the language design. I'm not sure if people are concerned about the debug cycle or production issues due to these proposed changes. There's simply no way around the fact that writing code for a dynamic programming model is going to result in more time spent verifying, testing, and debugging runtime issues; no matter the amount of effort expended on gathering the maximal amount of type information available from the dynamic language, or the call site symbols the programmer is required to enter to get the code to compile.

> On Dec 3, 2017, at 8:06 PM, Paul Cantrell via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> 
>> On Dec 3, 2017, at 1:26 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> On Dec 3, 2017, at 11:03 AM, Magnus Ahltorp <map at kth.se> wrote:
>>> 
>>>> 4 Dec. 2017 02:40 Chris Lattner via swift-evolution <swift-evolution at 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 community.
> 
> 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.
> 
> Cheers,
> 
> Paul
> 
> _______________________________________________
> 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171203/79d287c0/attachment.html>