I like Greg Parkers suggestion, if the extension is of a type that is not part of the project/library that is being developed then you don't need override. This would allow after-the-fact extensions to library and third-party structure/classes. It is also not confusing to human or compiler, since this is not source code you are looking at (by definition).
On Thursday, 7 January 2016, Matthew Johnson via swift-evolution < [email protected]> wrote: > > On Jan 6, 2016, at 3:48 AM, Greg Parker via swift-evolution < > [email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > > > On Jan 5, 2016, at 8:50 PM, Brent Royal-Gordon via swift-evolution < > [email protected] > <javascript:_e(%7B%7D,'cvml','[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. > > > Possible solution: if you want a new protocol adoption to map to some > existing method or property then you must explicitly write that. You can't > just adopt the protocol in an empty extension. > > extension Int: BoundedType { > static var min = Int.min > static var max = Int.max > } > > but with some other syntax that isn't ambiguous. Code completion and > compiler fix-its could suggest this when the class already implements > something suitable. > > > Another option might be to allow imported definitions to be used by a > conformance without the `override` marking to support retroactive modeling > while requiring definitions in the same module as the conformance to > explicitly specify the `override`. > > > > -- > Greg Parker [email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');> Runtime Wrangler > > > _______________________________________________ > swift-evolution mailing list > [email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');> > https://lists.swift.org/mailman/listinfo/swift-evolution > > > -- -- Howard.
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
