On Mon, Aug 21, 2017 at 5:51 AM David Hart via swift-evolution < [email protected]> wrote:
> On 21 Aug 2017, at 13:36, Adrian Zubarev <[email protected]> > 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 ([email protected]) schrieb: > > > On 21 Aug 2017, at 11:41, Adrian Zubarev <[email protected]> > 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 ( > [email protected]) 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
