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
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:
···
--
Adrian Zubarev
Sent with Airmail
Am 1. Juli 2017 um 01:55:47, Daryle Walker via swift-evolution (swift-evolution@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
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.
I’m not proposing anything right now. I’m asking a question; the proposal that needs the answer can be put off for later.
Given a type MyType, how can I get a type-alias to the type’s protocols? If MyType conforms to Protocol1 and Protocol2, I would want something like
typealias MyProtocol = Protocol1 & Protocol2
(and Any if MyType doesn’t conform to any protocols). Does this facility already exist in Swift? I don’t think it does, so I proposed the hybrid “MyType.Protocol” syntax to express the idea.
If you don’t like the current “.Protocol” syntax, then I guess you don’t like it for this idea. I’m also requesting suggestions for alternate syntax.
I’m not at a computer to test this, but would this work:
typealias T = P1 & P2
extension C: T {}
Now T is C.Protocol
···
On Jun 30, 2017, at 9:17 PM, Daryle Walker via swift-evolution <swift-evolution@swift.org> wrote:
On Jun 30, 2017, at 8:49 PM, Adrian Zubarev <adrian.zubarev@devandartist.com> wrote:
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.
I’m not proposing anything right now. I’m asking a question; the proposal that needs the answer can be put off for later.
Given a type MyType, how can I get a type-alias to the type’s protocols? If MyType conforms to Protocol1 and Protocol2, I would want something like
typealias MyProtocol = Protocol1 & Protocol2
(and Any if MyType doesn’t conform to any protocols). Does this facility already exist in Swift? I don’t think it does, so I proposed the hybrid “MyType.Protocol” syntax to express the idea.
If you don’t like the current “.Protocol” syntax, then I guess you don’t like it for this idea. I’m also requesting suggestions for alternate syntax.
Is C supposed to be a type or a protocol? I’m guessing a protocol since I don’t think “C.Protocol” is currently legal for a type. In either case, T wouldn’t include protocols introduced to C in some other way.
Regardless of the answers for your example, I don’t want to “write” new protocols to C, but “read” the protocols C already has.
The “MyType.Protocol” was a suggestion that I wondered if it would complicate parsing. Alternate syntax opinions requested.
···
On Jun 30, 2017, at 9:26 PM, Robert Bennett <rltbennett@icloud.com> wrote:
I’m not at a computer to test this, but would this work:
typealias T = P1 & P2
extension C: T {}
Now T is C.Protocol
—
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com
Leave the syntax aside. What are you planning to do with this feature? I understand that you want to have some way of saying "composition of all protocols this type conforms to"; I don't understand *why* you want it or what kind of code you would need it for.
···
On Jun 30, 2017, at 6:17 PM, Daryle Walker via swift-evolution <swift-evolution@swift.org> wrote:
Given a type MyType, how can I get a type-alias to the type’s protocols? If MyType conforms to Protocol1 and Protocol2, I would want something like
typealias MyProtocol = Protocol1 & Protocol2
(and Any if MyType doesn’t conform to any protocols). Does this facility already exist in Swift? I don’t think it does, so I proposed the hybrid “MyType.Protocol” syntax to express the idea.
It wasn’t until I started this thread that I realized that Swift didn’t have a way to get a bulk list of a type’s protocols. A little later, I came up with a reason why this never came up before (or at least not often): knowing this isn’t really useful.
You could use this to make MyTypeB conform to all protocols of MyTypeA. But then you’re stuck. The list of protocols for a type is a closed from the linker’s perspective, but open from the user’s perspective. The user couldn’t write all the methods needed unless the unknown ones all have default implementations. The proposal I’m coming up with has a facility to copy all the members of one type to another. You can specify by exact member name, or you can specify a protocol to get copies of all applicable members at once. This is where an all-protocols alias can help. With manual copying, the user’s cardinality of members copied is usually less than what’s available, with an automatic list the cardinalities are always equal.
···
On Jul 1, 2017, at 2:07 AM, Brent Royal-Gordon <brent@architechies.com> wrote:
On Jun 30, 2017, at 6:17 PM, Daryle Walker via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Given a type MyType, how can I get a type-alias to the type’s protocols? If MyType conforms to Protocol1 and Protocol2, I would want something like
typealias MyProtocol = Protocol1 & Protocol2
(and Any if MyType doesn’t conform to any protocols). Does this facility already exist in Swift? I don’t think it does, so I proposed the hybrid “MyType.Protocol” syntax to express the idea.
Leave the syntax aside. What are you planning to do with this feature? I understand that you want to have some way of saying "composition of all protocols this type conforms to"; I don't understand *why* you want it or what kind of code you would need it for.
—
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com
A full-fledged introspection system should provide this information, which I suppose could be useful for creating proxies through code generation or dynamic Objective-C like features, should they ever be added to the language. Would that be sufficient for your needs? It is not clear to me what problem you are trying to solve.
Hopefully I won't stir up too much trouble by saying that this kind of capability is very useful in Objective-C for mocking, for example.
···
On Jul 2, 2017, at 7:55 PM, Daryle Walker via swift-evolution <swift-evolution@swift.org> wrote:
On Jul 1, 2017, at 2:07 AM, Brent Royal-Gordon <brent@architechies.com <mailto:brent@architechies.com>> wrote:
On Jun 30, 2017, at 6:17 PM, Daryle Walker via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Given a type MyType, how can I get a type-alias to the type’s protocols? If MyType conforms to Protocol1 and Protocol2, I would want something like
typealias MyProtocol = Protocol1 & Protocol2
(and Any if MyType doesn’t conform to any protocols). Does this facility already exist in Swift? I don’t think it does, so I proposed the hybrid “MyType.Protocol” syntax to express the idea.
Leave the syntax aside. What are you planning to do with this feature? I understand that you want to have some way of saying "composition of all protocols this type conforms to"; I don't understand *why* you want it or what kind of code you would need it for.
It wasn’t until I started this thread that I realized that Swift didn’t have a way to get a bulk list of a type’s protocols. A little later, I came up with a reason why this never came up before (or at least not often): knowing this isn’t really useful.
You could use this to make MyTypeB conform to all protocols of MyTypeA. But then you’re stuck. The list of protocols for a type is a closed from the linker’s perspective, but open from the user’s perspective. The user couldn’t write all the methods needed unless the unknown ones all have default implementations. The proposal I’m coming up with has a facility to copy all the members of one type to another. You can specify by exact member name, or you can specify a protocol to get copies of all applicable members at once. This is where an all-protocols alias can help. With manual copying, the user’s cardinality of members copied is usually less than what’s available, with an automatic list the cardinalities are always equal.
—
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com
alter MyInt16: Int16, Hashable {
publish Equatable
var hashValue: Int {
return 2000 &+ super.hashValue
}
}
If I wanted to copy Int16 completely, I couldn’t write the full protocol list because it’s open-ended from the user’s perspective due to extensions. However, the list is closed from the compiler/linker’s perspective, so we can synthesize an all-protocol list:
alter MyInt16: Int16, protocols(Int16), ANewProtocol {
publish protocols(Int16)
// Define new members here, some of which implement ANewProtocol....
}
Besides this, maybe we could do some analysis using protocols(MyType).Protocol. (Oh, completely copying Int16 is still useful because functions with them are considered separate overloads, unlike a type-alias.)
I’m not sure what you mean by a full-fledged introspection system, but my current use for it requires a solution that is 100% workable at compile-time.
···
On Jul 2, 2017, at 10:15 PM, Christopher Kornher <ckornher@me.com> wrote:
A full-fledged introspection system should provide this information, which I suppose could be useful for creating proxies through code generation or dynamic Objective-C like features, should they ever be added to the language. Would that be sufficient for your needs? It is not clear to me what problem you are trying to solve.
Hopefully I won't stir up too much trouble by saying that this kind of capability is very useful in Objective-C for mocking, for example.
—
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com