[+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

Reply via email to