[swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

[Douglas Gregor]

> On May 17, 2016, at 6:43 AM, Adrian Zubarev via swift-evolution <swift-evolution at swift.org> wrote:
> 
> So basically everyone start to like by the core team suggested `Any<>` name of the proposed mechanism. I’ll rename it when I get home. ;)

Definitely happy to see this proposal being discussed (and happier if it uses “Any<>” :)).

> 
>> I don't think Either is a good name.  That implies 2 cases (either this or that).  Maybe 'OneOf' would be better.
> 
> Since that might be or be not a different proposal some day I guess we’d be safe to call it `OneOf` for the time being.
> 
> Would you mind to go over the rules I suggested? Do we need the ability to provide multiple reference/value types? I’d say no we don’t, to reduce confusion (see my proposal).
> 
> https://github.com/DevAndArtist/swift-evolution/blob/master/proposals/nnnn-mechanism-to-combine-types-and-protocols.md <https://github.com/DevAndArtist/swift-evolution/blob/master/proposals/nnnn-mechanism-to-combine-types-and-protocols.md>
You don’t seem to be tackling the case of “A Collection whose Element type is String”. If we’re generalizing the current “protocol<>” notion, why not make it as powerful as a generic signature, with the ability to specify same-type constraints and conformances on associated types?

	- Doug

> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 17. Mai 2016 bei 15:34:10, Matthew Johnson (matthew at anandabits.com <mailto:matthew at anandabits.com>) schrieb:
> 
>> 
>> 
>> Sent from my iPad
>> 
>> On May 17, 2016, at 5:12 AM, Adrian Zubarev via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>>> But don't you mean the union type of all possible Collection types when you write Any<Collection>?
>>>> 
>>>> I suggested `all<>` for the intersection type, and `any<>` for the union type, so that would be the same, wouldn't it?
>>> 
>>> Thats exactly how I understand out situation by now. I was confused by Thorsten's `intersection` first, but now I see that he meant the intersection between dynamic type and the whole set of constraints provided by `All<…>`. I thought about about the constraints union compared to the dynamic type, which is most likely the same thing.
>>> 
>>> In my proposal I reserved the name `Any<>` for future directions, but noted that we still might choose `Any<…>` for the proposed `All<…>` and then name `Any<…>` described by Thorsten as `Either<…>`.
>>> 
>> 
>> I agree with Brent's concept of Any.  That feels Swifty, following the convention established by the type-erasing wrappers currently in the standard library.  
>> 
>> I don't think Either is a good name.  That implies 2 cases (either this or that).  Maybe 'OneOf' would be better.
>>> 
>>>>  >> We've been over this a few times before on the list. I personally like naming this thing "Any<…>" in the same vein as "AnyObject", "AnyClass", and "AnySequence". I also see Thorsten (and in the past Brent's?) argument for calling it "all" or "All", because it's enforcing multiple constraints.
>>> 
>>>> > 
>>>> > I have suggested `all<>` in the past, but I now favor `Any`, because that allows it to be unified with the universal supertype `Any`, `Any<class>`, and things like `Any<Collection>` to forge the One Existential Syntax to rule them all.
>>> 
>>> I considered `Any<>` as an alternative and personally I don’t have anything against that little change. I still don’t like `AnyObject` because it uses `Object` instead of `Class`, where `AnyClass` is `AnyObject.Type`. This is way to confusing if you ask me. I’d rename both into `ClassInstance` == `AnyObject` and `ClassType` == `AnyClass`. If Swift one day might introduce `struct` and `enum` keywords that are generalized like `class` (could be) what name would you choose? Compared to `AnyClass` typealias `AnyStruct` would be `AnyXYZ.Type`. The only type I like which uses `Any` as its prefix is `Any` itself. 
>>> 
>>> But I guess this is something the core team will decide.
>>> 
>>> If there is no feedback towards the document I wrote anymore, I’ll submit a pull request later this day. (Note: I’ll add some small changes in the alternatives section about dropping the restriction of a single reference/value type within the angle brackets).
>>> 
>>> -- 
>>> Adrian Zubarev
>>> Sent with Airmail
>>> 
>>> Am 17. Mai 2016 bei 07:17:21, Thorsten Seitz via swift-evolution (swift-evolution at swift.org <mailto:swift-evolution at swift.org>) schrieb:
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160517/599b3da9/attachment.html>