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@swift.org> wrote:
> 
> 
>>> Am 03.12.2017 um 20:04 schrieb Magnus Ahltorp via swift-evolution 
>>> <swift-evolution@swift.org>:
>>> 
>>> 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.
> 
> 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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to