[swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

Matthew Johnson matthew at anandabits.com
Fri May 13 11:00:58 CDT 2016 

> On May 13, 2016, at 10:33 AM, Adrian Zubarev via swift-evolution <swift-evolution at 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 (matthew at anandabits.com <mailto:matthew at anandabits.com>) schrieb:
> 
>> 
>> 
>> Sent from my iPad
>> 
>> On May 13, 2016, at 9:21 AM, Tony Allevato via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at 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 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 <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 <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 <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 <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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/e2ecef20/attachment.html>

More information about the swift-evolution mailing list