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

[Thorsten Seitz]

> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171205/36ca1949/attachment.html>