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> 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> 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)
> 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
>
>
> _______________________________________________
> 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
