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.
···
On Aug 2, 2017, at 6:49 PM, Rock Yang <rockyang@icloud.com> wrote:
2017年8月2日 下午11:27，Gor Gyolchanyan via swift-evolution <swift-evolution@swift.org> 写道：
On Aug 2, 2017, at 6:15 PM, Taylor Swift <kelvin13ma@gmail.com <mailto:kelvin13ma@gmail.com>> 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 <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution