> On Aug 2, 2017, at 6:49 PM, Rock Yang <[email protected]> wrote: > > I found maybe it's unable to provide implementation in protocol declaration > which has associatedtype. > > Here is Sequence, which has Subsequence as associatedtype. AnySequence is > inferred if no custom Subsequence is declared. > > extension Sequence where Self.Element == Self.SubSequence.Element, > Self.SubSequence : Sequence, Self.SubSequence == Self.SubSequence.SubSequence > { > > /// Returns a subsequence containing all but the given number of initial > /// elements. > /// > /// If the number of elements to drop exceeds the number of elements in > /// the sequence, the result is an empty subsequence. > /// > /// let numbers = [1, 2, 3, 4, 5] > /// print(numbers.dropFirst(2)) > /// // Prints "[3, 4, 5]" > /// print(numbers.dropFirst(10)) > /// // Prints "[]" > /// > /// - Parameter n: The number of elements to drop from the beginning of > /// the sequence. `n` must be greater than or equal to zero. > /// - Returns: A subsequence starting after the specified number of > /// elements. > /// > /// - Complexity: O(1). > public func dropFirst(_ n: Int) -> AnySequence<Self.Element> > > I think it happened here. It's impossible to put this implementation in the > procotol body, even without the constraints. Compiler would never know, > dropFirst returns an AnySequence or associatetype Subsequence. >
This is a bit different. The implementation is provided in a constrained extension. Depending on the exact type that conforms to Sequence, it may or may not be implemented. Even so, that's unrelated to my original proposal. > > 2017年8月2日 下午11:27，Gor Gyolchanyan via swift-evolution > <[email protected]> 写道： > >> >>> On Aug 2, 2017, at 6:15 PM, Taylor Swift <[email protected] >>> <mailto:[email protected]>> wrote: >>> I agree with this, extensions on types defined in the same file are >>> generally silly, and default implementations belong in the protocol body. I >>> don’t agree with certain style guides prescription of same-file extensions; >>> they should only be used to hide protocol conformances that are >>> “unimportant” to the functionality of the type. In practice this means only >>> conformances like CustomStringConvertible and CustomDebugStringConvertible >>> live in extensions. >>> >>> If you want to group related methods, use linebreaks and whitespace for >>> that. Don’t split up the type braces since that messes up the whole >>> one-set-of-braces == one type definition visual rule. >>> >>> The only time it ever makes sense to extend a non concrete type that you >>> own is when adding conditional default implementations. Having to extend a >>> bare protocol is the product of a language limitation. >> >> Take a look at my replies to Tino Heth about code locality and the rest... >> >>> On Wed, Aug 2, 2017 at 6:26 AM, Tino Heth via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>>> That would work as well, but it has the downside of forcing a potentially >>>> huge number of methods to be implemented in a single place, reducing the >>>> readability as opposed to packing them into semantically related groups in >>>> the form of extensions. >>> >>> I really don't get why people are so obsessed with same-file extensions: >>> They are recommended in style guides, influencers blog about them, and they >>> motivated a ridiculous complex change in the access rights system. Yet I >>> haven't seen any evidence that they offer real benefit. >>> Extensions are great for adding useful helpers to existing types, and still >>> allow you to selectively expose details of your own classes — but most >>> people seem to ignore those options and focus on something can be done >>> better with plain old comments. >>> [sorry for the rant — but I think a critical look at extensions is long >>> overdue: I rarely see someone questioning their role, so basically, we are >>> making important decisions based on pure superstition] >>> >>> A protocol itself is already a vehicle to group related methods, and if you >>> have a huge entity, it doesn't get better just because you split it and >>> hide its complexity. >>> >>>> Also, please include the original message for reference purposes. >>> [hopes Discourse will happen soon ;-) ] >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >>> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
