[swift-evolution] Constrained Protocol Aliases

Matthew Johnson matthew at anandabits.com
Mon Aug 21 10:43:35 CDT 2017 

> On Aug 21, 2017, at 10:31 AM, Adrian Zubarev <adrian.zubarev at devandartist.com> wrote:
> 
> 
> Hi Matthew thank you for remembering us about that draft. I’ll re-read it soon. At the a quick glance I noticed the extent use of the `where` clause. Wouldn’t make sense to simplify the main proposal and just focus on the `where` clause for typealises only? It’s already a complex feature on its own. Permitting the `where` clause in different places can sill be added later in the future.

At first glance, it looks to me like the typealias would need to refer to a generalized existential anyway and if we can do that through a typealias we should probably be able to do it directly as well.  That said, if it simplifies the implementation in some way it might make sense as a first step.  Whether or not that would be the case is something I can’t speak to with any confidence.

> 
> Am 21. August 2017 um 15:10:34, Matthew Johnson (matthew at anandabits.com <mailto:matthew at anandabits.com>) schrieb:
> 
>> If anyone is thinking about spending time on this topic I recommend beginning by reviewing the prior work that was done by Austin Zheng.  He has a proposal draft for enhanced existential that is very thorough.  Even if you're not planning to propose everything that's included in his draft it would be a good idea to be familiar with it.  Here's the link: https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/XXXX-enhanced-existentials.md <https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/XXXX-enhanced-existentials.md>.
>> 
>> Sent from my iPad
>> 
>> On Aug 21, 2017, at 6:36 AM, Adrian Zubarev via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> It’s part of Generalized Existentials, but does not make it complete. I think it would be worth adding more and more functionality to existentials every year. We started first with reshaping the syntax. This year we added support for classes. I think next year would be good to have where clause support for typealiases.
>>> 
>>> I understand the complexity of that particular feature, and it’s a no-go for me to help on the implementation, but I’m willing to drive the discussion and the proposal forward with other co-authors. :)
>>> 
>>> Hasn’t it been said that the implementation must be at least a *proof-of-concept* if the complexity is very high?
>>> 
>>> And my second question is: Wouldn’t the existence of this feature reshape some parts of the standard library, isn’t that affecting some major goals of Swift 5?
>>> 
>>> It would be nice if someone from the core team can clarify if the where clause is out of scope for Swift 5 or not.
>>> 
>>> 
>>> 
>>> 
>>> Am 21. August 2017 um 12:51:48, David Hart (david at hartbit.com <mailto:david at hartbit.com>) schrieb:
>>> 
>>>> 
>>>>> On 21 Aug 2017, at 11:41, Adrian Zubarev <adrian.zubarev at devandartist.com <mailto:adrian.zubarev at devandartist.com>> wrote:
>>>>> 
>>>>> Yes, `where` clause is welcome to typealises (including generic ones) and existentials in general. I would love to help on such proposal. I think David Hart is also interested in this one. (cc)
>>>> 
>>>> Yes, this basically seems like Generalized Existentials to me and is mentioned in the Generics Manifesto <https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md>. It’s a feature I hold very dear but:
>>>> 
>>>> It’s a very difficult feature to implement and I think Doug Gregor is the only/best person to do it
>>>> I think its pretty much out of scope for Swift 5 (it’s not required for ABI Stability)
>>>> 
>>>> As a result, I’d be very surprised if this topic got any discussion or implementation time during the Swift 5 timeframe.
>>>>> Am 21. August 2017 um 11:38:14, Gor Gyolchanyan via swift-evolution (swift-evolution at swift.org <mailto:swift-evolution at swift.org>) schrieb:
>>>>> 
>>>>>> Hello, Swift community!
>>>>>> 
>>>>>> I'd like to start a discussion about a possibility of constrained protocol aliases. The declaration would look like this:
>>>>>> 
>>>>>> typealias BinaryProtocol = RandomAccessCollection & MutablCollection & RangeReplaceableCollection where Binary.Index == Int, Binary.Element == Bool
>>>>>> 
>>>>>> The syntax and semantics of this declaration are exactly the same as an analogous associatedtype declaration inside a protocol.
>>>>>> In the example above, the type BinaryProtocol represents a logical array of bits and is a generic-only protocol that is usable in any context where an integer-indexed mutable range-replaceable random-access collection is expected.
>>>>>> Now, it can be used in a very concise and elegant way:
>>>>>> 
>>>>>> public protocol BinaryInitializable {
>>>>>> init<Binary>(binary: Binary) where Binary: BinaryProtocol
>>>>>> }
>>>>>> 
>>>>>> which would otherwise look very verbose and inelegant:
>>>>>> 
>>>>>> public protocol BinaryInitializable {
>>>>>> init<Binary>(binary: Binary) where Binary: RandomAccessCollection & MutablCollection & RangeReplaceableCollection, Binary.Index == Int, Binary.Element == Bool
>>>>>> }
>>>>>> 
>>>>>> Considering that smaller sets of constraints could be aliased to their own protocol and then composited into more complex aliases, this feature would dramatically improve readability and maintainability of code that uses complex constraints, that currently leads to arcane mess:
>>>>>> 
>>>>>> struct Mirror {
>>>>>> /// ...
>>>>>> init<Subject, C where C : Collection, C.Indices : Collection, C.SubSequence : Collection, C.Indices.Index == C.Index, C.Indices.SubSequence == C.Indices, C.Iterator.Element == Mirror.Child, C.SubSequence.Index == C.Index, C.SubSequence.Indices : Collection, C.SubSequence.SubSequence == C.SubSequence, C.Indices.Iterator.Element == C.Index, C.SubSequence.Indices.Index == C.Index, C.SubSequence.Indices.SubSequence == C.SubSequence.Indices, C.SubSequence.Iterator.Element == Mirror.Child, C.SubSequence.Indices.Iterator.Element == C.Index>(_ subject: Subject, children: C, displayStyle: Mirror.DisplayStyle? = default, ancestorRepresentation: Mirror.AncestorRepresentation = default)
>>>>>> /// ...
>>>>>> }
>>>>>> 
>>>>>> 
>>>>>> /// A collection that is its own sub-sequence
>>>>>> typealias RecursivelySliceableCollection = Collection where
>>>>>> RecursivelySliceableCollection.SubSequence: Collection,
>>>>>> RecursivelySliceableCollection.SubSequence.Element == RecursivelySliceableCollection.Element
>>>>>> RecursivelySliceableCollection.SubSequence.Indices == RecursivelySliceableCollection.Indices,
>>>>>> RecursivelySliceableCollection.SubSequence.SubSequence == RecursivelySliceableCollection.SubSequence
>>>>>> 
>>>>>> /// A collection that is its own index collection
>>>>>> typealias RecursivelyIndexableCollection = Collection where
>>>>>> RecursivelyIndexableCollection.Indices == RecursivelySliceableCollection,
>>>>>> RecursivelyIndexableCollection.Indices.Index == RecursivelyIndexableCollection.Index,
>>>>>> 
>>>>>> struct Mirror {
>>>>>> /// ...
>>>>>> init<Subject, C: RecursivelySliceableCollection & RecursivelyIndexableCollection, where  C.Element == Mirror.Child>(_ subject: Subject, children: C, displayStyle: Mirror.DisplayStyle? = default, ancestorRepresentation: Mirror.AncestorRepresentation = default)
>>>>>> /// ...
>>>>>> }
>>>>>> 
>>>>>> Even considering that the proposal SE-0157 (https://github.com/apple/swift-evolution/blob/master/proposals/0157-recursive-protocol-constraints.md <https://github.com/apple/swift-evolution/blob/master/proposals/0157-recursive-protocol-constraints.md>) is going to make this specific use case a non-issue, the principle applies to all cases where there are commonly used complex constraints that don't necessarily involve recursive constraints.
>>>>>> 
>>>>>> Specializing Generic-Only Protocols For Non-Generic Use
>>>>>> 
>>>>>> An additional feature that would prove to be very useful would be to make a constrained protocol alias be a non-generic-only protocol if the constraints of the alias declaration specify a same-type requirement for all its associated types, while defaulted associated types would also count.
>>>>>> Example:
>>>>>> 
>>>>>> protocol Consumer {
>>>>>> associatedtype Consumable
>>>>>> mutating func consume(_ consumable: Consumable) throws
>>>>>> }
>>>>>> 
>>>>>> var consumer0: Consumer // error: Consumer is only usable in a generic context
>>>>>> 
>>>>>> typealias CharacterConsumer = Consumer where  CharacterConsumer.Consumable == Character
>>>>>> 
>>>>>> var consumer1: CharacterConsumer // OK
>>>>>> 
>>>>>> The current workaround would be to declare a new protocol with protocol inheritance clauses and a where clause, but the major downside is that it introduces a completely new protocol that is not compatible with any context that expects the underlying protocols and their constraints.
>>>>>> 
>>>>>> Regards,
>>>>>> Gor Gyolchanyan.
>>>>>> 
>>>>>> _______________________________________________
>>>>>> 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170821/9623f5cb/attachment.html>

More information about the swift-evolution mailing list