> On 21 Aug 2017, at 13:36, Adrian Zubarev <adrian.zuba...@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. > 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 (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 https://lists.swift.org/mailman/listinfo/swift-evolution