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