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