> 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.
Another example where potential failure is not apparent to the caller:
struct Foo {
var bar: Int
}
struct Example {
var n: Int
var foo: Foo { return Foo(bar: n + 1) }
}
let a = Example(n: Int.max)
a.foo.bar
Swift doesn't save the caller in this case, so together with Chris' example, I
don't really understand the "not apparent to the caller" argument. Crashability
is totally in the hands of the implementor of a method or member access, now
and with the proposal.
/Magnus
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
