> "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.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
