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)?
>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<>`? 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 } One benefit of `any<>` is the replacement of overloading, at least for the type part of the function. I’d like to propose `type<>` as the base extension to the language in that direction, before we’ll move forward with more complex scenarios (just like Chris did with generic typealias). This function is clear that it only will work if you provide a subclass of an UIView which conforms to SomeProtocol (nice addition for library design). func foo(value: type<UIView, SomeProtocol>) -> type<UIView, SomeProtocol> { // use it as a UIView and SomeProtocol at the same type return value // return type works great } We can split the value just fine: let mergedValue = foo(SomeViewThatWorks) let view: UIView = mergedValue let protocolValue: SomeProtocol = mergedValue And merge it back together: guard let newMergedValue = view as? type<UIView, SomeProtocol> else { /* do something */ } `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<>`. -- Adrian Zubarev Sent with Airmail Am 12. Mai 2016 bei 21:40:24, Thorsten Seitz (tseit...@icloud.com) 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 <swift-evolution@swift.org>: 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 (sva...@gmail.com) schrieb: protocol<> _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution