[swift-evolution] Constrained Protocol Aliases

[Tony Allevato]

On Mon, Aug 21, 2017 at 5:51 AM David Hart via swift-evolution <
swift-evolution at swift.org> wrote:

> On 21 Aug 2017, at 13:36, Adrian Zubarev <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.
>

For what it's worth, the updated README on swift-evolution says:

"Beyond ABI stability (which focuses mostly on getting a bunch of low-level
implementation details of the language finalized), in Swift 5 the evolution
process welcomes additions that improve the overall usability of the
language and standard library"

So it sounds like they're willing to consider proposals outside of
ABI+concurrency—and though I can't speak for the core team's motivation, it
seems like requiring an implementation before formal review means that
proposals beyond their primary focus have a greater chance of making it
into the language than they did before.


> 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.
>
> 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.
>
>
> Am 21. August 2017 um 12:51:48, David Hart (david at hartbit.com) schrieb:
>
>
> On 21 Aug 2017, at 11:41, 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)
>
>
> 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) 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)
> 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
> 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/20170821/e0d0661b/attachment.html>