> On Aug 21, 2017, at 5:51 AM, David Hart <[email protected]> wrote:
>
>
>> On 21 Aug 2017, at 13:36, Adrian Zubarev <[email protected]
>> <mailto:[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.
The main issue is the implementation: it’s a nontrivial feature with impact on
the AST, type checker, SIL, IR generation, type metadata, and runtime. On the
other hand, it’s one of these features that’s 95% testable refactoring: one can
plumb the notion of “generalized existential” through the whole compiler as a
generalization of the existing existential types. The core abstraction needed
to capture the requirements on the existential (GenericSignature) is already
there in the compiler for generics, and much of the task is to generalize (as
appropriate) and use that machinery for existentials.
It’s not an easy feature, but there are many capable people who could do it,
and of course we’ll be happy to give guidance/review over on swift-dev if
someone would like to work on it. The refactoring I mentioned could be
developed on master (incrementally) as a general improvement to the compiler,
so the implementation of the feature itself is a small, more
syntactically-focused separate piece.
>> 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.
Generalized existentials would affect some parts of the standard library (e.g.,
they’d be a better way to implement AnyCollection et al), but generalized
existentials are not a game-changer for the design.
>> 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.
It’s not “out of scope”, but everything hinges on the implementation task.
- Doug
>
>>
>> Am 21. August 2017 um 12:51:48, David Hart ([email protected]
>> <mailto:[email protected]>) schrieb:
>>
>>>
>>>> On 21 Aug 2017, at 11:41, Adrian Zubarev <[email protected]
>>>> <mailto:[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] <mailto:[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
>>>>>
>>>>> <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] <mailto:[email protected]>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>>
>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
