[swift-evolution] Proposal: typealias support protocol constraint

[QQ Mail]

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 at 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 <cantrell at pobox.com <mailto:cantrell at 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<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 <swift-evolution at swift.org <mailto:swift-evolution at 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<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 <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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 <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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
>>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>> 
>>>> 
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> 
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151228/7c252193/attachment.html>