> On May 13, 2016, at 10:33 AM, Adrian Zubarev via swift-evolution > <swift-evolution@swift.org> wrote: > >> >> But maybe we should consider generalizing this to type operators. The '?' >> For optional could then be a postfix type operator. And we could define our >> own type operators for type composition. > > Would you mind to provide a more detailed design from your perspective? I > mean, how do you imagine `type<>` aka. `all<>` to look like with operators? > >
The & type operator would produce a “flattened" all<> with its operands. It could be overloaded to accept either a concrete type or a protocol on the lhs and would produce `type` for an lhs that is a type and `all` when lhs is a protocol. "Type operators” would be evaluated during compile time and would produce a type that is used where the expression was present in the code. This is a long-term idea, not something that needs to be considered right now. It would be way out of scope for Swift 3. > Any feedback is welcome. :) > > -- > Adrian Zubarev > Sent with Airmail > > Am 13. Mai 2016 bei 17:05:29, Matthew Johnson (matt...@anandabits.com > <mailto:matt...@anandabits.com>) schrieb: > >> >> >> Sent from my iPad >> >> On May 13, 2016, at 9:21 AM, Tony Allevato via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> 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. >> >> +1 >> >> But maybe we should consider generalizing this to type operators. The '?' >> For optional could then be a postfix type operator. And we could define our >> own type operators for type composition. >> >>> >>> 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. >> >> This makes sense as an immediate step in the right direction. I like that >> it is more concise than protocol<> >>> >>> >>> 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 > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
