> This has been suggested before, usually in the form of a separate `implement` keyword. The main problem is that it makes it impossible to write a protocol after the fact which formalizes some existing pattern in the types.
I think this is a great point and would be a con that I hadn't considered in terms of Howard's suggestion that everything implementing a protocol should have use a keyword (such as "override" or "implement"). I fear that I've explained my idea a little poorly. My thought was that *only methods overriding something*--namely, a default implementation given in a protocol extension--should be required to use the override keyword when the method is dynamically dispatched. It would remain very much possible to formalize an existing pattern because, in the case of your example (unless I'm misunderstanding?), you are not also providing a default implementation of the "min" and "max" getters, and the IntXX structs would have nothing to override. Indeed, you'd hardly be formalizing an existing pattern if you had to supply de novo implementations! It's true that it's possible to do something in today's Swift syntax that wouldn't be possible in my proposal. Namely, in today's Swift syntax, it's possible to give a dynamically dispatched default implementation of the min and max getters in an after-the-fact formalization, but I have trouble seeing any circumstance in which that would be necessary--unless I misunderstand, such a default implementation can never be invoked? On Tue, Jan 5, 2016 at 10:50 PM, Brent Royal-Gordon <[email protected]> wrote: > > Taking inspiration from syntax used for methods in classes that override > methods in superclasses, require methods that override dynamically > dispatched default implementations in protocol extensions to use the > override keyword. Likewise, forbid the override keyword if the method being > implemented instead 'masks' (would that be the right word?) a statically > dispatched method in a protocol extension which can nonetheless be invoked > by upcasting to the protocol. > > This has been suggested before, usually in the form of a separate > `implement` keyword. The main problem is that it makes it impossible to > write a protocol after the fact which formalizes some existing pattern in > the types. > > What do I mean by that? Well, imagine you need generic access to the `min` > and `max` static properties of the various integer types. There's no > existing protocol that includes those members. But you can write one and > then extend the integer types to conform to your new protocol: > > protocol BoundedIntegerType: IntegerType { > static var min: Self { get } > static var max: Self { get } > } > extension Int: BoundedType {} > extension Int8: BoundedType {} > extension Int16: BoundedType {} > extension Int32: BoundedType {} > extension Int64: BoundedType {} > > func printLowestPossibleValueOfValue<Integer: > BoundedIntegerType>(x: Integer) { > print(Integer.min) > } > > This only works because `min` and `max` *don't* need any special marking > to be used to satisfy a requirement. Requiring a keyword like you suggest > would remove that feature. > > -- > Brent Royal-Gordon > Architechies > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
