[+swift-evolution] Sure! It's just a fancy word for doing something like this:
protocol SelfAppendable { init() func +=(other: Self) } func *<Sequence: SelfAppendable >(sequence: Sequence, count: Int) -> Sequence { var result = Sequence() for _ in 0..<count { result += sequence } return result } extension Array: SelfAppendable {} extension String: SelfAppendable {} Both Array and String already have no-argument initializers and a += function, but they come from the standard library and don't (necessarily) satisfy any protocols, so they wouldn't be declared "implement". I can think of a few different ways to deal with this, but mostly I just want to make sure you (and everyone else) are considering this use case in your proposal. :-) Best, Jordan > On Mar 18, 2016, at 17:04 , Victor Gao <victorga...@gmail.com> wrote: > > Hi Jordan, > > Could you explain more of what retroactive modeling is and how it affects the > proposal? I am unfamiliar with retroactive modeling. Thanks! > > Victor Gao. > >> On Mar 18, 2016, at 21:01, Jordan Rose <jordan_r...@apple.com >> <mailto:jordan_r...@apple.com>> wrote: >> >> I feel like this should be added to the "common proposal caveats", but >> please include a discussion of how this affects retroactive modeling (adding >> a protocol to a type you don't own that already has the appropriate >> members). Previous discussions about "implement" (usually "implements") >> usually fizzle out at this point. >> >> (IIRC last time we got to "it's required if the member is in the same >> module, but allowed to be absent otherwise", which is fairly reasonable but >> probably still needs to be thought through.) >> >> Jordan >> >> >>> On Mar 18, 2016, at 16:58 , Victor Gao via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >>> Hello everybody. Please excuse this proposal’s poor formatting. I am very >>> new to swift-evolution and don’t yet know how to do a formatted proposal. :) >>> >>> >>> Proposal >>> >>> I am proposing to add an implement keyword to go with protocol method >>> implementations like the override keyword. >>> >>> >>> Motivation >>> >>> When writing an implementation for a protocol method, there is no >>> indication that the method is an implementation of a protocol method. >>> Unless it is a well-known protocol like UITableViewDataSource, there is >>> simply no way to know if the method is provided by a protocol or the >>> enclosing class. Right now, the only way to guess if a method is >>> protocol-provided is if it follows the pattern of someObjectOrView(_: >>> requestSomething:) or someObjectOrView(_: somethingDidHappen:). But since >>> non-Cocoa protocol methods may not follow that pattern, they will not be so >>> easy to guess. Here’s an example illustrating the problem: >>> >>> func recordInDatabase(database: TJDatabase, atIndexPath indexPath: >>> NSIndexPath) -> TJRecord { >>> //… >>> } >>> >>> Is this a protocol method implementation, or simply a method declaration? >>> Well, it looks like a protocol method implementation, but how can one be >>> sure? There is no way to definitely know unless you are familiar with it or >>> you found its declaration after searching in the whole project, worse in >>> huge projects. The method above just seems too “ordinary” to be a protocol >>> method implementation. Even worse, some developer might come around and >>> even rename that method, and there would be an error, then he has to fish >>> around for the protocol method he’s missing. Assuming that he finally found >>> it (if the protocol is small enough), he might even implement it again with >>> the same code as the renamed method. We can see the problem here. >>> >>> Or, let’s think about this: how would it feel if there is no override >>> keyword? How would one know if a method is an override or not? We can see >>> how this relates to the confusion with protocol method implementations. >>> >>> >>> Proposed solution >>> >>> The proposed solution is to add an implement keyword, which improves the >>> code above to this: >>> >>> implement func recordInDatabase(database: TJDatabase, atIndexPath >>> indexPath: NSIndexPath) -> TJRecord { >>> //… >>> } >>> >>> Now it is very clear that we are implementing a protocol method rather than >>> declaring a method. The code is much clearer, and it doesn’t hurt the >>> readability either. >>> >>> >>> Detailed design >>> >>> When overriding implemented protocol methods from a superclass, the >>> override keyword is still used: >>> >>> override func recordInDatabase(database: TJDatabase, atIndexPath indexPath: >>> NSIndexPath) -> TJRecord { >>> return super.recordInDatabase(database, atIndexPath: indexPath) >>> } >>> >>> Impact on existing code >>> >>> Existing code would be changed to include the implement keyword in >>> appropriate places. This could be handled via the Swift latest syntax >>> converter in Xcode. >>> >>> >>> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution