+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
