Sent from my iPad
> On May 13, 2016, at 9:21 AM, Tony Allevato via swift-evolution
> <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> 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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
