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

[Paul Cantrell]

I’m not sure this solves the Ruby ergonomics problem. Picking up from an earlier thread:

Chris wrote:
> Paul wrote:
>> An “always use parens” bridge to Ruby has bad ergonomics
>> Zero-arg Ruby methods are a mixture of property-like things that would certainly not use parens in Swift, and function-like things that certainly would:
>> 
>>     // Idiomatic Swift:
>>     post.author.name.reversed()
>> 
>>     // Swift bridging to Ruby…
>> 
>>     // …if no-args methods •must• use parens:
>>     post.author().name().reverse()
>> 
>>     // …if no-args methods •can’t• use parens:
>>     post.author.name.reverse
>> 
>> If the goal is to make Swift mostly feel like Swift even when bridging to Ruby, then the bridge needs to support both access forms.
> 
> Ok, that can certainly be implemented by the two proposals I have in flight.  No obvious problem there.


Chris, can you elaborate? I think the proposal precludes this; I must be missing something!

As I read the proposal, the dynamic member subscript for post.author returns either a property value or a DynamicCallable, depending on whether the thing is a property or a method — but post.author and post.author() would both look identical to that subscript implementation, and there’s no distinction on the Ruby side, so the subscript can’t know which one to return.

The getter could return something that is both a dynamic callable and has dynamic members that lazily make the implicit method call. But this has two serious problems:

1. The necessarily lazy evaluation of the property value leads to nightmare scenarios:

    post.author = sally
    let oldAuthor = post.author()
    post.author = fred
    oldAuthor.name  // "Sally"

    // but

    post.author = sally
    let oldAuthor = post.author
    post.author = fred
    oldAuthor.name  // "Fred"

2. This precludes bridging to Swift types, e.g. Ruby strings → Swift strings.

Therefore it seems the proposal forces post.author().name().reverse(). Something I'm missing?

Cheers,

Paul


> On Nov 27, 2017, at 12:04 AM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I’d like to formally propose the inclusion of user-defined dynamic member lookup types.
> 
> Here is my latest draft of the proposal:
> https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438
> https://github.com/apple/swift-evolution/pull/768
> 
> An implementation of this design is available here:
> https://github.com/apple/swift/pull/13076
> 
> The implementation is straight-forward and (IMO) non-invasive in the compiler.
> 
> -Chris
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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