[swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>
Vladimir.S
svabox at gmail.com
Fri May 13 10:59:46 CDT 2016
IMO it will be nice to have ability to write:
func f(obj: A&B&C) {..}
if obj is A&B&C {...}
obj2 = obj as! A&B&C
(but I still don't understand real use case of things like (String | Int))
Btw, as we have `protocol` keyword for this feature to couple protocols,
why we can't have `class` keyword to merge class&protocols?
Like
func f(obj: class<SomeClass,SomeProtocl>) {..}
if obj is class<SomeClass,SomeProtocl> {..}
obj2 = obj as! class<SomeClass,SomeProtocol>
and yes, probably struct<SomeStruct,SomeProtocol>
On 13.05.2016 17:21, Tony Allevato via swift-evolution 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.
>
> 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 at swift.org <mailto:swift-evolution at 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 at swift.org <mailto:swift-evolution at 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 (tseitz42 at icloud.com
>> <mailto:tseitz42 at 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 at swift.org <mailto:swift-evolution at 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 (svabox at gmail.com
>>>> <mailto:svabox at gmail.com>) schrieb:
>>>>
>>>>> protocol<>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
More information about the swift-evolution
mailing list