> Am 14.05.2016 um 20:08 schrieb Thorsten Seitz via swift-evolution > <swift-evolution@swift.org>: > >> protocols conformance of `type<>` is tested with the actual type `type<>` >> not with the first element of `type<>` (hard to describe this one, does this >> makes sense to you?) > > The components of type<> are unrelated and do not have to conform to each > other. They are just a union type. Did you mean that?
Ooops, I meant of course, the complete expression forms an *intersection* type (not a union type). To recap: In Ceylon A & B is an intersection type which means a type that conforms to A *and* B. This could be written as all<A, B> in Swift. In Ceylon A | B is a union type which means a type that conforms to A *or* B (maybe to both but at least to one of them). This could be written as any<A, B> in Swift. -Thorsten > > -Thorsten > >> Does this proposal need more than the base `type<>`? >> >> Maybe, but I think we should start with `type<>` before we will introduce a >> type operator for this. >> >> Did I missed anything out here? >> >> PS: Feel free to help me with my English, because it’s not so well. >> >> -- >> Adrian Zubarev >> Sent with Airmail >> >> Am 13. Mai 2016 bei 16:21:41, Tony Allevato (allev...@google.com >> <mailto:allev...@google.com>) schrieb: >> >>> I think there would be a certain elegance to allowing Boolean type >>> expressions wherever types are currently allowed, so `A & B` being a >>> replacement for `protocol<A, B>` might look nice, and then extend that to >>> allow concrete types as well. Then, if Swift ever decided to support union >>> types, the `|` operator naturally fits there. >>> >>> One concern though would be whether parsing would get more complicated with >>> deeply composed expressions. If we only supported `&`, there's no real >>> nesting going on. But if we wanted to be forward thinking and leave the >>> door open for `|`, we might need to support things like `(String | Int) & >>> SomeProtocol`, and I'm not enough of a parser expert to know whether that >>> would really complicate things (e.g., could the compiler decide easily >>> enough that those parentheses are part of a type expression and not a >>> function type?). >>> >>> `all<A, B>` would be a nice compromise in that case, and leave the door >>> open for `any<A, B>` in the future. So I'd be supportive of either option. >>> >>> >>> On Thu, May 12, 2016 at 1:30 PM Jordan Rose via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> 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 will say that "type" is unlikely to see much traction simply because it >>> is an incredibly common name for both properties and locals. We went >>> through that exercise when trying to name both "static" and "dynamicType" >>> and decided that it would be too confusing, even if we could make the >>> parsing work. >>> >>> The feature itself has definitely been shown to be useful when working with >>> the Cocoa frameworks, if not in general. I don't see it on JIRA yet but we >>> have it internally tracked in Radar as rdar://problem/15873071 <>. >>> >>> Jordan >>> >>> >>>> On May 12, 2016, at 13:08, Adrian Zubarev via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>> >>>> 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 >>>> <mailto: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 <mailto: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 >>>>>> <mailto:sva...@gmail.com>) schrieb: >>>>>> >>>>>>> protocol<> >>>>>> _______________________________________________ >>>>>> 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 <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 <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
