> Am 13.05.2016 um 17:25 schrieb Adrian Zubarev via swift-evolution > <swift-evolution@swift.org>: > > Lets sum things up before I try to write a draft proposal for this feature > `type<>` aka `all<>`. > > Is this feature out of scope for Swift 3? > > From my point of view it’s definitely not. > > Is the name `type<>` really that bad for the compiler? > > Here I’m not sure, because that is out of my experience. From a readers > perspective it’s more clear than `all<>`, I would say, even though this is a > perfect explanation why it should be called `all<>`: > >> I also see Thorsten (and in the past Brent's?) argument for calling it "all" >> or "All", because it's enforcing multiple constraints. > > Do we miss any rules here? > > `type<>` can contain only one value-type or reference-type and n protocols > the value-type or reference-type should always be the first element between > angle brackets > `type<>` should always contain at least 2 types (one value-type or a > reference-type and at least one protocol) I think type<> (or all<>) should replace protocol<>, otherwise the idea of having all<> and any<> loses its charm. Is there a reason why type<> should exist in parallel to protocol<>? > reference-types do represent a possible super/base type/class > nesting `type<>` is not allowed, however `type<>` can contain `protocol<>` > 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?
-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 > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
