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

> 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

Reply via email to