+1 for Thorsten’s `dynamic` and `dynamic?`.

-- Howard. 

> On 6 Dec 2017, at 6: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