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

[Tino Heth]

> "Have the compiler specifically bless individual well-known types, e.g. Python.PyVal (or whatever it is eventually named) by baking in awareness of these types into the compiler. Such an approach would require a Swift evolution proposal to add a new type that conforms to this."
> +1
I have strong bias against special cases in the compiler (well, actually, against special cases in general ;-).
Imho it’s preferable to keep the compiler simple, and change it only for thinks you can’t do with a library.

> I think there are a very finite number of programming languages Swift would like to have this kind of interop with, and i think having every new case reach into core team would also be a good opportunity to reevaluate that part of the language.
I’m pro reevaluation, but what could be the outcome? This process only makes sense if it is an option to roll back changes that don’t work as well as expected.

> IIUC, this is also the most controlled version of the proposal, and it prevents all abuses, while enabling the most seamless experience for python developers. So, it looks perfect to me.

I may have missed some changes in direction, but afair, it was a strong point in the early revisions of the proposals that the suggested changes are useful in general, and not Python-specific…
Also, I don’t think anything can prevent all abuses (it’s an subjective classification anyways) — people might just use PyVals because dynamic behavior, and that would imho be a huge abuse.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171205/15157aae/attachment.html>