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.
Sent from my iPad
> On Aug 21, 2017, at 6:36 AM, Adrian Zubarev via swift-evolution
> <swift-evolution@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 (da...@hartbit.com) schrieb:
>
>>
>>> On 21 Aug 2017, at 11:41, Adrian Zubarev <adrian.zuba...@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. 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@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@swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
