> Am 29.05.2016 um 18:07 schrieb Austin Zheng <[email protected]>:
>
>
>> On May 29, 2016, at 7:04 AM, Matthew Johnson <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>
>> This makes a lot more sense! So you want to be able to use uninhabitable
>> types in the contexts of things like collection elements (such collections
>> must always be empty but are inhabitable by a single empty instance). It is
>> a great example of why it might make sense to allow types like this.
>>
>> What you are really asking for is the ability to drop the restriction that
>> only a single superclass constraint is allowed and no value type constraints
>> are allowed. It might be useful in cases like your intersection example.
>> But it could also be a source of error confusing error messages when people
>> form such a type and it doesn't work the way they expect. If the type is
>> disallowed as under the current proposal the error message might be more
>> straightforward. This is a topic that probably deserves further
>> consideration. But I have to say I find your intersection example to be
>> reasonably compelling.
>>
>> Austin, what do you think about this example?
>
> I personally don't feel like the additional complexity is worth it as Swift
> exists today.
I agree that adding a bottom type would be a different proposal. As an
intermediate step we could just make it a type error if an existential would
only be satisfied by the bottom type.
-Thorsten
>
> Swift getting a real bottom type would be a completely different proposal. It
> would allow you to do things like:
>
> let universalNil : Bottom? = nil
> var a : Int? = universalNil
> var b : UIView? = universalNil
>
> and so on.
>
> If Swift does ever get such a type relaxing the restriction from the proposal
> would be an additive change, and could be proposed separately as a follow up
> addition.
>
> Austin
>
>
>>
>>>
>>> -Thorsten
>>>
>>>
>>>>
>>>> To write this `union` and have it behave in the usual way you need `Any<A,
>>>> B>` to be a supertype of `A` and of `B`. The existential doesn’t actually
>>>> do that so it would not be possible for this union function to guarantee
>>>> the result would have all of the members of `x` and all the members of `y`
>>>> the way that a `union` usually would.
>>>>
>>>> The anonymous union type `A | B` *is* a supertype of `A` and a supertype
>>>> of `B` so you would have no trouble writing this:
>>>>
>>>> func union<A, B>(x: Set<A>, y: Set<B>) -> Set<A | B> { … }
>>>>
>>>> And returning the expected result.
>>>>
>>>>>
>>>>>
>>>>> -Thorsten
>>>>>
>>>>>
>>>>>
>>>>>> Am 26.05.2016 um 07:53 schrieb Austin Zheng via swift-evolution
>>>>>> <[email protected] <mailto:[email protected]>>:
>>>>>>
>>>>>> 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
