> On May 26, 2016, at 6:08 AM, Matthew Johnson <[email protected]> wrote:
>
>
>
> Sent from my iPad
>
> On May 26, 2016, at 6:59 AM, Taras Zakharko via swift-evolution
> <[email protected] <mailto:[email protected]>> wrote:
>
>> This looks very nice!
>>
>> Two questions/comments
>>
>> 1. I would prefer to write simpler existential types without Any, e.g.:
>>
>> let a: Sequence where Sequence.Iterator.Element == Int
>>
>> Is there a reason why we need Any<> at all, aside as a parsing aid?
>>
>> 2. If this proposal gets accepted, does it mean that type-erased wrappers
>> like AnySequence become superfluous? They always struck me as a hack, used
>> only to overcome the limitations of the type system.
>
> Many type-erase wrappers will be unnecessary. However, if you look at
> AnyCollection it defines AnyIndex. You can pass values of this type that
> come from one value of AnyCollection to another AnyCollection even if it has
> a totally different underlying type. In other words, it is explicitly type
> unsafe and will call fatalError if you use a bad index.
I think this actually shouldn't be a problem anymore (warning, strawman syntax):
func doSomethingWithTwoCollections(x: Any<Collection>, y: Any<Collection>) {
let anIndex : x.Index = x.startIndex
var anotherIndex : y.Index = y.startIndex
// NOT ALLOWED - x.Index and y.Index are not equivalent
anotherIndex = anIndex
// With the new collection model (SE-0065), indices are simply Comparable now
// Okay to cast from x.Index to Comparable
let a = anIndex as Comparable
// Not okay to cast from Comparable to y.Index
let b = a as y.Index
// This should be okay. We may want to break this feature into 'Opening
Existentials' follow-up proposal
if let b = a as? y.Index {
// do stuff with b
}
}
>
> If you want behavior like that you will still have to implement it manually.
> But it's probably more an artifact of the state of the language at the time
> AnyCollection was designed than anything else. I think we'd prefer safe
> behavior, which is possible with the latest update to this proposal (exposing
> associated types as 'anonymous types' where safe use with the existential
> that produced them is well defined) .
>
>>
>> Best,
>>
>> Taras
>>
>>
>>
>>> On 26 May 2016, at 07:53, Austin Zheng via swift-evolution
>>> <[email protected] <mailto:[email protected]>> wrote:
>>>
>>> The inimitable Joe Groff provided me with an outline as to how the design
>>> could be improved. I've taken the liberty of rewriting parts of the
>>> proposal to account for his advice.
>>>
>>> It turns out the runtime type system is considerably more powerful than I
>>> expected. The previous concept in which protocols with associated types'
>>> APIs were vended out selectively and using existentials has been discarded.
>>>
>>> Instead, all the associated types that belong to an existential are
>>> accessible as 'anonymous' types within the scope of the existential. These
>>> anonymous types are not existentials - they are an anonymous representation
>>> of whatever concrete type is satisfying the existential's value's
>>> underlying type's associated type.
>>>
>>> This is an enormous step up in power - for example, an existential can
>>> return a value of one of these anonymous associated types from one function
>>> and pass it into another function that takes the same type, maintaining
>>> perfect type safety but without ever revealing the actual type. There is no
>>> need anymore to limit the APIs exposed to the user, although there may
>>> still exist APIs that are semantically useless without additional type
>>> information.
>>>
>>> A set of conversions has also been defined. At compile-time 'as' can be
>>> used to turn values of these anonymous associated types back into
>>> existentials based on the constraints defined earlier. 'as?' can also be
>>> used for conditional casting of these anonymously-typed values into
>>> potential actual types.
>>>
>>> As always, the link is here, and feedback would be greatly appreciated:
>>> 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>
>>>
>>> Best,
>>> Austin
>>>
>>> On Tue, May 24, 2016 at 5:09 AM, Matthew Johnson via swift-evolution
>>> <[email protected] <mailto:[email protected]>> wrote:
>>>
>>>
>>> Sent from my iPad
>>>
>>> On May 23, 2016, at 9:52 PM, Brent Royal-Gordon via swift-evolution
>>> <[email protected] <mailto:[email protected]>> wrote:
>>>
>>> >> One initial bit of feedback - I believe if you have existential types,
>>> >> I believe you can define Sequence Element directly, rather than with a
>>> >> type alias. e.g.
>>> >>
>>> >> protocol Sequence {
>>> >> associatedtype Element
>>> >> associatedtype Iterator: any<IteratorProtocol where
>>> >> IteratorProtocol.Element==Element>
>>> >> associatedtype SubSequence: any<Sequence where Sequence.Element ==
>>> >> Element>
>>> >> …
>>> >> }
>>> >
>>> > That's not really the same thing. Any<IteratorProtocol> is an
>>> > existential, not a protocol. It's basically an automatically-generated
>>> > version of our current `AnyIterator<T>` type (though with some additional
>>> > flexibility). It can't appear on the right side of a `:`, any more than
>>> > AnyIterator could.
>>>
>>> After this proposal you should be able to use these existentials anywhere
>>> you can place a constraint, so it would work. You can do this with the
>>> protocol composition operator today and the future existential is just an
>>> extension of that capability.
>>>
>>> >
>>> > What *would* work is allowing `where` clauses on associated types:
>>> >
>>> >> protocol Sequence {
>>> >> associatedtype Element
>>> >> associatedtype Iterator: IteratorProtocol where
>>> >> Iterator.Element==Element
>>> >> associatedtype SubSequence: Sequence where SubSequence.Element ==
>>> >> Element
>>> >> …
>>> >> }
>>> >
>>> > I believe this is part of the generics manifesto.
>>> >
>>> > --
>>> > Brent Royal-Gordon
>>> > Architechies
>>> >
>>> > _______________________________________________
>>> > 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] <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] <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] <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
