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

[Tony Allevato]

I'm +1 on this. It seems like it would solve the issue of Objective-C APIs
losing their protocol conformances on properties/arguments/return values
when they're added to a class, like UIView<SomeProtocol>. That always
seemed like a major hole in the cross-language support and when writing
ObjC libraries I've had to explicitly use id<Foo> instead of a stronger
class-based type simply to ensure Swift interoperability.

The other option of course is to import those things as generic functions
with constraints, but (1) that doesn't solve it for properties, and (2) if
we already support composing protocols in this way, why not also allow it
for other types, where it can be used for properties and variables? This
approach feels like it would round out the type system nicely.


On Thu, May 12, 2016 at 7:09 AM Adrian Zubarev via swift-evolution <
swift-evolution at swift.org> wrote:

> 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) schrieb:
>
> protocol<>
>
> _______________________________________________
> 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/20160512/d141fb73/attachment.html>