> On May 17, 2016, at 6:43 AM, Adrian Zubarev via swift-evolution > <swift-evolution@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 (matt...@anandabits.com > <mailto:matt...@anandabits.com>) schrieb: > >> >> >> Sent from my iPad >> >> On May 17, 2016, at 5:12 AM, Adrian Zubarev via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>) schrieb: >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
