On Apr 28, 2016, at 10:00 PM, Jordan Rose <[email protected]> wrote: > 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
I've arrived at the "just table it and find something more productive to work on" stage. This pitch grew out of my conviction that doing "near miss" detection was the wrong approach for supporting and documenting developer intent decisions. If there's no strong support my the core concept (enhancing safety by introducing semantic compiler hints) then all the implementation details in the world don't get me anywhere. Without developing a quorum that supports the underlying philosophy, regardless of implementation, I'm not going to push this any further. The gist is updated but I have no plans to further mold it into a proposal. -- E
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
