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

[Thorsten Seitz]

> Am 06.12.2017 um 02:38 schrieb Chris Lattner <clattner at nondot.org>:
> 
> On Dec 5, 2017, at 11:13 AM, Thorsten Seitz <tseitz42 at icloud.com> wrote:
>>> 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.
> 
> Then, by your definition, Swift must not have a static type system.   Two examples:
> 
>    x.b       // when x is an IUO
>    a + b    // as implemented today in the Python bridge prototype I sent out.
> 

IUO is Swift’s equivalent to a null pointer and those are a _hole_ in the type system (this applies to all type systems having an equivalent to the null pointer). That is why such types are marked with "!“ in Swift.
This does not mean that Swift has no type system but that it’s type system has carefully marked holes.

-Thorsten