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 < [email protected]> 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 ([email protected]) schrieb: > > protocol<> > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
