[swift-evolution] Would having "MyType.Protocol" to indicate a type's protocols mess anything up?

Adrian Zubarev adrian.zubarev at devandartist.com
Fri Jun 30 19:49:15 CDT 2017


What are you proposing here, I don’t get it?! What role should .Protocol play? .Protocol is an ugly hack in Swift which should be removed anyway. It does more harm than good.

Our revised proposal was deferred from Swift 4:

https://github.com/DevAndArtist/swift-evolution/blob/refactor_existential_metatypes/proposals/0126-refactor-metatypes.md



-- 
Adrian Zubarev
Sent with Airmail

Am 1. Juli 2017 um 01:55:47, Daryle Walker via swift-evolution (swift-evolution at swift.org) schrieb:

We have

MyType.Type

to indicate the meta-type of a type. And

MyProtocol.Protocol

to indicate the meta-type of a protocol. Would it be OK to add

MyType.Protocol

to identify all the protocols MyType follows? The result would be like if each protocol was connected by “&”, or “Any” if the type doesn’t follow any protocols.

…

Woah, I realized that this could be a bigger than anticipated. A type can specify its protocols directly, or through extension(s). Heck, I do that in my Cocoa projects to segregate each aspect of a class. So I guess we have to allow the protocol list to include those imported via extensions.

…

Why do I want to do this? It’s part of my retype/strong-typedef/alternate-interface idea. I originally made the developer list each protocol to re-implment separately in the export list and the protocol list. But that would be tedious for a long list of protocols. So I’m thinking “why not have a way to specify all of the protocols at once.” But I’m not sure on the syntax, that’s why I’m asking here. Alternatives could be things like “#protocolof(MyType)”. Unless we already have this capability?…

(Having a retype that repeats all of the implementation type’s protocols is still useful. The types would have the same interface, but still don’t share function overloads.)

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

_______________________________________________
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/20170701/5f72fdf2/attachment.html>


More information about the swift-evolution mailing list