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@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@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

Reply via email to