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
> <[email protected]> 写道：
>
> 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 <[email protected]
>> <mailto:[email protected]>> 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<CollectionType where
>> 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
>>> <[email protected] <mailto:[email protected]>> 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<CollectionType where CollectionType.Generator.Element == CGPoint>
>>>
>>> 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<CollectionType where Generator.Element == CGPoint>
>>>
>>> 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 Dec 6, 2015, at 4:28 AM, Adrian Kashivskyy via swift-evolution
>>>> <[email protected] <mailto:[email protected]>> wrote:
>>>>
>>>> I believe this could be achieved using generic typealiases, proposed here:
>>>> https://lists.swift.org/pipermail/swift-evolution/2015-December/000132.html
>>>>
>>>> <https://lists.swift.org/pipermail/swift-evolution/2015-December/000132.html>
>>>>
>>>> Pozdrawiam – Regards,
>>>> Adrian Kashivskyy
>>>>
>>>>> Wiadomość napisana przez QQ Mail via swift-evolution
>>>>> <[email protected] <mailto:[email protected]>> w dniu
>>>>> 06.12.2015, o godz. 08:17:
>>>>>
>>>>> If typealias support protocol constraint, I think we can reuse a lot of
>>>>> code, also more readable
>>>>>
>>>>> For Example:
>>>>>
>>>>> typealias PointCollection = protocol<T:CollectionType where
>>>>> T.Generator.Element == CGPoint>
>>>>>
>>>>> public extension PointCollection {
>>>>>
>>>>>
>>>>>
>>>>> }
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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] <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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
