On Nov 15, 2017, at 2:52 PM, Jean-Daniel via swift-evolution <swift-evolution@swift.org> wrote: > Just a question about what it mean for API resilience. Actually, adding a > property to an existing class is not a breaking change. > > For a class that implements that protocol, as it will be possible to use > property accessor with any non existing property. Adding a new property to > this class will now change the class behavior in unexpected way as the old > client will still call the dynamic lookup method, but new code will use the > new accessor method. Is it something that should be mention in the « Effect > on API resilience » section ?
Right. Sure, I’ll add a mention of that. -Chris > > >> Le 15 nov. 2017 à 08:29, Chris Lattner via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit : >> >> Hi All, >> >> As a peer to the DynamicCallable proposal >> (https://gist.github.com/lattner/a6257f425f55fe39fd6ac7a2354d693d >> <https://gist.github.com/lattner/a6257f425f55fe39fd6ac7a2354d693d>), I’d >> like to get your feedback on making member lookup dynamically extensible. >> My primary motivation is to improve interoperability with dynamic languages >> like Python, Perl, Ruby, Javascript, etc, but there are other use cases >> (e.g. when working with untyped JSON). >> >> In addition to being a high impact on expressivity of Swift, I believe an >> implementation can be done in a way with changes that are localized, and >> thus not have significant impact on the maintainability of the compiler as a >> whole. Once the pitch phase of this proposal helps refine the details, I’ll >> be happy to prepare an implementation for consideration. >> >> In case it is useful, I’m working on cleaning up my current prototype Python >> bindings. I’ll share them in the next day or two in case they are useful to >> provide context. It is amazingly simple: less than 500 lines of Swift code >> (plus some small additional C header glue to work around clang importer >> limitations) enables impressive interoperability. The only problems are the >> verbosity addressed by this proposal and the peer DynamicCallable proposal. >> >> >> Here is the canonical proposal URL: >> https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438 >> <https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438> >> >> A snapshot of the proposal is included below in case it is useful. Thanks >> in advance for help improving the proposal! >> >> -Chris >> >> >> Introduce User-defined "Dynamic Member Lookup" Types >> >> Proposal: SE-NNNN >> <https://gist.github.com/lattner/NNNN-DynamicMemberLookup.md> >> Author: Chris Lattner <https://github.com/lattner> >> Review Manager: TBD > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
