> Am 03.12.2017 um 20:04 schrieb Magnus Ahltorp via swift-evolution
> <[email protected]>:
>
>> 4 Dec. 2017 02:40 Chris Lattner via swift-evolution
>> <[email protected]> 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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
