[resending without quoting the proposal, because apparently that made Mail emit
garbage today]
Hi, Erica. Sorry for not participating in the first round here. I’m…not so
happy with this direction, for a number of reasons. (I apologize for the
laundry list, but they’re not really related complaints.)
- ‘required’ already means something today: it means “this initializer must be
present on all subclasses”. The reason it only applies to initializers is
because all other members are always present on all subclasses.
(Counter-argument: using ‘required’ on an initializer could be seen as making
an implicit protocol, just for that class hierarchy.)
- ‘override’ likewise already has a meaning; allowing ‘override’ to be
satisfied by a protocol requirement means that it might miss an override
intended for a superclass—or inadvertently become one when an SDK is updated.
(Counter-argument: that last can happen to protocols already.)
- This doesn’t cover cases where methods in one protocol extension satisfy
requirements in another.
- This doesn’t cover retroactive modeling.
- I’m not sure what it means to "prefer an overridden implementation in
preference in reverse hierarchical order: type extensions take precedence over
type declarations over protocol extensions over protocol declarations (assuming
protocol declarations eventually adopt default implementations)”. Protocol
conformance is decided at compile time; there won’t ever be any members in type
extensions that take precedent over a type declaration without causing a
conflict. (That is, currently you are not allowed to define such a member.)
- A member in the type does not “override" a member in a protocol extension
today, because such a call is not dynamically dispatched. Making protocol
extension members dynamically dispatched is challenging at the least and would
require an implementation plan in the proposal.
- Thank you for writing up all of the source compatibility cases! I think
there’s no issue with binary compatibility, since IIUC the proposal doesn’t
change how anything is implemented, and we think we know how to handle binary
compatibility there. But I’d like to think about it a little more.
- The “A.foo(self)()” syntax is clever, but it doesn’t work correctly for
mutating methods (because you can’t curry an inout). On the other hand, JoeG
already brought up the idea of making ‘self’ the first argument of the implicit
static member. It still doesn’t solve the problem of picking a protocol
extension, but that’s not new. (This isn’t a complaint, I guess, just a note.)
I’m not sure I have a meaningful summary or conclusion, but I’d be hesitant to
do all of this without these concerns being addressed.
Jordan
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
