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

[Chris Lattner]

> On Nov 30, 2017, at 10:26 PM, Slava Pestov <spestov at apple.com> wrote:
> 
> 
> 
>> On Nov 30, 2017, at 10:23 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> The difference between it and AnyObject lookup is that AnyObject lookup is:
>> 
>> b) type unsafe
> 
> Can you explain in what sense AnyObject lookup is type unsafe where your proposal is type safe? Both seem type safe in the sense that your program will not hit undefined behavior at runtime and instead trap if you access a non-existent member; both are type unsafe in the sense that you cannot reason statically about whether any specific member lookup will succeed. What is the distinguishing characteristic between the two that makes one safe and the other not?

The Objective-C runtime does not track the type of members or methods.  The Clang importer uses the same heuristic approach that Objective-C/Clang/GCC do.  If you have something of type “id” named “x”, when you write “x.foo” if there is a declaration of “foo” in some class in some imported header, it will assume it has the type of that declaration.  While this is an important heuristic, this is not always the case, and does in fact cause bugs in users code.

In contrast, the DynamicMemberLookup proposal itself is fully type safe (three fully type safe implementation approaches are explained in it) and the Python interop layer I’m prototyping uses it.

-Chris


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