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 > <[email protected]> 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 > ([email protected] <mailto:[email protected]>) 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 >> [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
