> On May 29, 2016, at 7:04 AM, Matthew Johnson <[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.
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
