> On Aug 21, 2017, at 10:31 AM, Adrian Zubarev > <adrian.zuba...@devandartist.com> wrote: > > > Hi Matthew thank you for remembering us about that draft. I’ll re-read it > soon. At the a quick glance I noticed the extent use of the `where` clause. > Wouldn’t make sense to simplify the main proposal and just focus on the > `where` clause for typealises only? It’s already a complex feature on its > own. Permitting the `where` clause in different places can sill be added > later in the future.
At first glance, it looks to me like the typealias would need to refer to a generalized existential anyway and if we can do that through a typealias we should probably be able to do it directly as well. That said, if it simplifies the implementation in some way it might make sense as a first step. Whether or not that would be the case is something I can’t speak to with any confidence. > > Am 21. August 2017 um 15:10:34, Matthew Johnson (matt...@anandabits.com > <mailto:matt...@anandabits.com>) schrieb: > >> 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 >> >> <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 <mailto: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 >>> <mailto:da...@hartbit.com>) schrieb: >>> >>>> >>>>> On 21 Aug 2017, at 11:41, Adrian Zubarev <adrian.zuba...@devandartist.com >>>>> <mailto: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 >>>> <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@swift.org <mailto: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 >>>>>> >>>>>> <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 <mailto:swift-evolution@swift.org> >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
