Chris Lattner wrote: > Also, if I were to nitpick your argument a bit, it isn’t true that the > protocol knows “nothing" about the type anyway, because the protocol has > access to self. The default implementation could conceptually use reflection > to access all the state in the type: we’re producing the same effect with > more efficient code.
I had to go back to first principles because it seems to violate the separation of reflection and base-level that has been a keystone of the mirrors I invented for Self. (When Gilad & I wrote our paper on this, he called this separation the principle of "stratification.") So, I thought about why I believed in that separation in the first place. I think the key thought was to insulate clients of an abstraction from changes in its implementation. I went back to the proposal and realized that it ensured such insulation by excluding extensions: > Requirements will be synthesized only for protocol conformances that are part > of the type declaration itself; conformances added in extensions will not be > synthesized. Also, the exclusion of classes avoids problems with inheritance. Bottom line: The proposal won't create problems arising from coupling clients to implementations. The restrictions are crucial. When this new feature is documented (in the Swift book?), this decoupling might be helpful to motivate the restrictions. - David _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
