[swift-evolution] Constrained Protocol Aliases
Douglas Gregor
dgregor at apple.com
Mon Aug 21 11:22:37 CDT 2017
> On Aug 21, 2017, at 5:51 AM, David Hart <david at hartbit.com> wrote:
>
>
>> On 21 Aug 2017, at 13:36, Adrian Zubarev <adrian.zubarev at devandartist.com <mailto:adrian.zubarev at devandartist.com>> 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?
>>
> I’d love to have this feature. But I’m not sure even a partway proposal will get to review with the laser-focus on ABI Stability + Concurrency. I don’t want to spend time co-authoring a proposal if it is going to be out of scope anyway. Perhaps Doug (CC) can give us some ideas.
The main issue is the implementation: it’s a nontrivial feature with impact on the AST, type checker, SIL, IR generation, type metadata, and runtime. On the other hand, it’s one of these features that’s 95% testable refactoring: one can plumb the notion of “generalized existential” through the whole compiler as a generalization of the existing existential types. The core abstraction needed to capture the requirements on the existential (GenericSignature) is already there in the compiler for generics, and much of the task is to generalize (as appropriate) and use that machinery for existentials.
It’s not an easy feature, but there are many capable people who could do it, and of course we’ll be happy to give guidance/review over on swift-dev if someone would like to work on it. The refactoring I mentioned could be developed on master (incrementally) as a general improvement to the compiler, so the implementation of the feature itself is a small, more syntactically-focused separate piece.
>> 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?
>>
> Yes. But that also true of many other language feature. But the Standard Library still needs to be set in stone at some point or another.
Generalized existentials would affect some parts of the standard library (e.g., they’d be a better way to implement AnyCollection et al), but generalized existentials are not a game-changer for the design.
>> 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.
>>
> Agreed.
It’s not “out of scope”, but everything hinges on the implementation task.
- Doug
>
>>
>> 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>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170821/9f2e7650/attachment.html>
More information about the swift-evolution
mailing list