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

[C. Keith Ray]

static type checking is no guarantee of program correctness. 

you can take a correct, functioning program in Java, for example, strip out all the type declarations and change the syntax to Groovy, and still have a correct, functioning program.

(if you avoid methods overloaded on parameter type)

with polymorphism via protocols, classes, etc., we don't have guarantees that the method invoked at runtime is actually going to behave correctly because behavior != type. 

polymorphism gives us advantages that make up for the lack of determinism.

the *code* calling a method should not have to care whether the object is using static dispatch, dynamic dispatch, or even remote-procedure calls. I kinda miss Objective-C's "Dynamic Objects" proxy objects which could forward method calls across process boundaries and over networks. 

obviously the *programmer* cares about additional failure cases involved for remote proxies, but there's no reason for different *syntax*.

C. Keith Ray
https://leanpub.com/wepntk <- buy my book?
http://agilesolutionspace.blogspot.com/
twitter: @ckeithray
http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf

> On Dec 5, 2017, at 11:13 AM, Thorsten Seitz via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>>> Am 03.12.2017 um 20:04 schrieb Magnus Ahltorp via swift-evolution <swift-evolution at swift.org>:
>>> 
>>> 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.
> 
> I just wanted to add that the single purpose of a static type system is to ensure that the methods being called on a receiver are present at runtime and take arguments of the types known at compile time. Of course the type system does not guarantee that those calls to not fail. Even in Haskell there is no guarantee that a function call does not fail as it allows partial patterns (therefore `head []` crashes). Or a function call might enter an infinite loop. But, to repeat, the type system guarantees that the method or member itself will be present.
> 
> Therefore I cannot follow the argument that it follows from the possible failure of a Swift method or member access that it is ok or even a comparable type of failure if the method or member itself is not present. This would imply that Swift’s static type system is unnecessary. Why check for the presence of a method or member if calling it or accessing it might fail anyway? No, I do not buy that argument. And I do not think that I have to provide examples where a static type system is of help.
> 
> The remaining question therefore is whether it is ok to remove the static type system for certain isolated use cases and that might be the case. But I like others would prefer if those use cases would be isolated somehow visually. Someone proposed to require `dynamic` before expressions containing dynamic member lookups similar to `try`, with the additional option to enclose a whole block into `dynamic { … }` to express the same as prefixing each expression with `dynamic`. I still think this has merit:
> 
> ````
> let result = dynamic x.foo.bar  // will crash if foo or bar are not present
> 
> let result = dynamic? x.foo.bar // will return nil if foo or bar are not present
> 
> // will crash if foo or bar are not present
> let result = dynamic {
> 	let y = x.foo.bar
> 	let z = y.baz(42)
> 	return z.zork()
> }
> 
> // will return nil if foo or bar are not present
> let result = dynamic? {
> 	let y = x.foo.bar
> 	let z = y.baz(42)
> 	return z.zork()
> } 
> ````
> 
> It allows to clearly demarcate the border between regions which are fully statically type checked and those where the static type system be only partially available (depending on the types of the respective receivers) while not being very intrusive due to the block notation. 
> Of course I can still have a mixture of static and dynamic member accesses _within_ a dynamic block but at least I know that when I am outside of such a block there won’t be any dynamic member accesses. None. Zero.
> 
> -Thorsten
> 
> _______________________________________________
> 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/20171205/c17bc553/attachment.html>