Resending message to list. Seems like iOS Mail (or me) really has problems with setting the reply to the list automatically :-( Thanks, Adrian, for notifying me.
-Thorsten Anfang der weitergeleiteten E‑Mail: > Von: Adrian Zubarev <[email protected]> > Datum: 13. Mai 2016 um 16:50:52 MESZ > An: Thorsten Seitz <[email protected]> > Betreff: Re: [swift-evolution] [Pitch] merge types and protocols back > together with type<Type, Protocol, ...> > > Your message was private, maybe by accident? Consider to resend it to the > public thread if you’d like. ;) > > -- > Adrian Zubarev > Sent with Airmail > > Am 13. Mai 2016 bei 08:16:51, Thorsten Seitz ([email protected]) schrieb: > >> >> >> Am 12. Mai 2016 um 22:08 schrieb Adrian Zubarev via swift-evolution >> <[email protected]>: >> >>> I don’t get the part how `all<>` should allow `any<>`. Could you explain >>> that a little bit in detail (I’m not familiar with Ceylon)? >> >> >> `all<>` and `any<>` form a pair of complementary type operators, one >> creating the intersection of the given types (your proposal) and the other >> creating the union of the given types. As Ceylon has demonstrated that both >> are really useful I'd like to have both in Swift and therefore would prefer >> that both should be named such that this duality is visible. Having `type<>` >> and `any<>` would certainly be possible technically but the naming would not >> be good. >> >>> >>> From my point of view `any<>` is something different that I pitched here. >>> `any<>` could be proposed in its own thread, because it is way different >>> than `type<>`. Or can we refine the rules of `type<>` to get to `any<>`? >> >> >> You are right, `any<>` is something different and could be proposed in its >> own thread. I just wanted to extend the context for finding a good name for >> `type<>`. >> >>> >>> Here is a little example where `any<>` gets strange: >>> >>> func foo(value: any<String, Int>) -> any<String, Int> { >>> >>> // how would one use value here? >>> // what about its properties >>> // what will foo return and how to use the result >>> } >> >> >> Ceylon uses flow typing for that (if (is String value) { /* value has type >> String here */ }). >> In Swift the equivalent would be `if let string = value as? String { ... }`: >> >> func foo(value: any<Strint, Int>) -> any<String, Int> { >> if let string = value as? String { >> return string.characters.count >> } >> else if let int= value as? Int { >> return String(int) >> } >> } >> >> A more sensical example using a type union would be the union of two sets: >> >> func union<T, U>(a: Set<T>, b: Set<U>) -> Set<any<T, U>> { ... } >> >> And for type intersection the intersection of two sets: >> >> func intersection<T, U>(a: Set<T>, b: Set<U>) -> Set<all<T, U>> { ... } >> >> (Ceylon's type operators just read better there...) >> >> Another example for type unions: >> Ceylon like Swift makes heavy use of optionals but where Swift has a generic >> wrapper Optional<T> Ceylon just makes use of type unions: in Ceylon T? is >> syntactic sugar for the type union T | Null where Null is the type having >> the singleton value null. >> >> FWIW Microsoft's Typescript gained union and intersection types about (I >> think) a year ago. >> >>> >>> One benefit of `any<>` is the replacement of overloading, at least for the >>> type part of the function. >> >> >> Exactly. >> >> >>> `all<>` could be seen as an alternative name for `type<>`, but to me its >>> not clear what `all<>` can do, whereas `type<>` is almost like `protocol<>`. >> >> >> Right, `all<>` is just an alternative name for `type<>`. There is no change >> in functionality. >> >> -Thorsten >> >> >>> >>> -- >>> Adrian Zubarev >>> Sent with Airmail >>> >>> Am 12. Mai 2016 bei 21:40:24, Thorsten Seitz ([email protected]) schrieb: >>> >>>> >>>> Ceylon uses „&" for intersection types, i.e. >>>> >>>> SomeRealClass & SomeProtocol >>>> >>>> and the bar („|“) for union types, i.e. >>>> >>>> String | Int >>>> >>>> That has proven to be very lightweight and readable in Ceylon where it is >>>> heavily used to good effect. >>>> >>>> >>>> I agree with you that >>>> >>>> type<SomeRealClass, SomeProtocol> >>>> >>>> is much nicer than protocol<> for intersection types but to keep the door >>>> open for union types, I would prefer >>>> >>>> all<SomeRealClass, SomeProtocol> >>>> >>>> This would allow >>>> >>>> any<String, Int> >>>> >>>> to be used for union types. >>>> >>>> -Thorsten >>>> >>>> >>>>> Am 12.05.2016 um 16:09 schrieb Adrian Zubarev via swift-evolution >>>>> <[email protected]>: >>>>> >>>>> protocol<SomeRealClass, SomeProtocol> >>>>> protocol<SomeRealStruct, SomeProtocol> >>>>> >>>>> This feels really odd to me. >>>>> >>>>> `type<SomeRealClass, SomeProtocol>` is more clear I’d say. >>>>> >>>>> I think this would be a good addition to the type system and allow us to >>>>> build more complex and type save code. >>>>> >>>>> But still I’d love to discuss if there might be any disadvantages to this >>>>> feature. >>>>> >>>>> -- >>>>> Adrian Zubarev >>>>> Sent with Airmail >>>>> >>>>> Am 12. Mai 2016 bei 15:11:00, Vladimir.S ([email protected]) schrieb: >>>>> >>>>>> protocol<> >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> [email protected] >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
