It’s a little be late to bring this out, but I have some new thoughts on it ~
First of all, this proposal basic concept is for easier and clearly to write
Protocol extension.
So this means the “PointCollection" still a protocol, So why not use protocol
inheritance to define it.
What about we just write it like this:
public protocol PointCollection:CollectionType where T.Generator.Element ==
CGPoint {}
extension PointCollection {
// extension methods
}
and for multiple protocol conformation we can still use typealias, which
currently supported, etc:
typealias CombinedProtocol = protocol<ProtocolA, ProtocolB, ProtocolC>
> 在 2015年12月7日，上午3:27，Matthew Johnson via swift-evolution
> <swift-evolution@swift.org> 写道：
>
> Yes, the idea is that this protocol type with partially or totally bound
> associated types would be valid anywhere you could use a type.
>
> I’m not a compiler developer and I’m sure there are implementation
> complexities and a lot of subtleties to work through. But I believe it is
> possible as Swift’s protocols share many similarities with ML’s module system
> and ML is able to do this.
>
> Hopefully someone from the core team can chime in on feasibility,
> desirability, and priority of a feature like this.
>
>
>> On Dec 6, 2015, at 1:22 PM, Paul Cantrell <cantr...@pobox.com
>> <mailto:cantr...@pobox.com>> wrote:
>>
>>> The general form of this would look like:
>>>
>>> protocol<P1, P2, P3 where *list of constraints*>
>>
>>
>> I’m very interested in this. Would this also extend to variables &
>> parameters with generic types that are only constrained, or not specified at
>> all? For example:
>>
>> let heterogeneousCollections: protocol> Generator.Element: CollectionType> = whatever
>>
>> …or even:
>>
>> let heterogeneousCollections: [CollectionType] = whatever
>>
>> …because we don’t need to know the element types to get the max count:
>>
>> let maxSize = heterogenousCollections.map { $0.count }.maxElement()
>>
>> If so, I’m desperate for this. The lack of it forced some ugly compromises
>> in Siesta’s API.
>>
>> Cheers, P
>>
>>
>>> On Dec 6, 2015, at 9:07 AM, Matthew Johnson via swift-evolution
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>
>>> This request isn’t really about typealias at all. It has two elements.
>>>
>>> First, it’s about the ability to bind Self and / or associated types in a
>>> protocol and use the result as a type. This is highly desirable and is
>>> similar to features in the ML module system.
>>>
>>> First is the ability to use a protocol with self or associated types as a
>>> type, not just a generic constraint:
>>>
>>> protocol
>>>
>>> I don’t think the `T:` label is necessary here as the protocol name serves
>>> as a good identifier in this context. Although the protocol name could
>>> probably be omitted when there is only one protocol here as it is implicit:
>>>
>>> protocol
>>>
>>> The general form of this would look like:
>>>
>>> protocol<P1, P2, P3 where *list of constraints*>
>>>
>>> In this case the protocol name would be required, at least when more than
>>> one protocol in the list have an associated type with the same name (and
>>> possibly in all cases). The list of constraints could identify associated
>>> types, bind them to concrete types, constrain Self to a specific
>>> superclass, etc. The Self constraint might look like this:
>>>
>>> protocol<P1, P2, P3 where Self: UIViewController>
>>>
>>> Ideally we would not need to bind all associated types in the protocol in
>>> order to use it at a type, but would only be allowed to use members that do
>>> not mention the unbound associated type in their signature.
>>>
>>> Once we have the ability to bind associated types and use the result as a
>>> type, the typealias use falls out automatically.
>>>
>>> Second, it’s about the ability to extend a typealias where some generic
>>> constraints are specified in the typealias. This would allow us to re-use
>>> the binding of generic constraints, but could be confusing if the extension
>>> is far removed in source from the typealias. I’m not sure how I feel about
>>> this part of the proposal.
>>>
>>> Matthew
>>>
>>>> On
