[swift-evolution] Constrained Protocol Aliases

[Gor Gyolchanyan]

I'm not very familiar with the Swift compiler codebase and it would take me more time to implement this than someone that has already contributed before. Considering that since Swift 5 proposals are required to include a pull request with an implementation, it would be much faster if someone with better knowledge of the compiler codebase would help me with the implementation, so a formal proposal could be made.

So... If someone wants to pitch in and help implement this, I'd be very grateful! 🙂

I do want to get around to study the compiler's code inside-and-out, but that's an asynchronous process.

> On Aug 21, 2017, at 12:41 PM, Adrian Zubarev <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)
> 
> 
> 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170821/9087348b/attachment.html>