I would like to be able to get, at runtime, an array of all types conforming to a particular protocol. (Similarly, I would like to be able to get an array of all subtypes of a given type). Is this in the generics manifesto? If not, can it be added? What is the timeframe?
It seems to me, that the compiler should actually already have this information, and it is just a matter of keeping it around when it is requested. I could be wrong about that though...
Why do I want this? It would make a lot of things like plug-ins and extensible factories possible (and much easier where they are possible). For example, you could add a new type to a factory (without the factory having to be coupled to it) just by adhering to a protocol. It would also make building a swift version of NSCoding much easier.
I have asked for other, more complicated, language features (e.g. handler funcs) to make those possible before, and I still want them (since I have used them in other languages and it was enormously powerful), but I realized that I should actually be able to make most of those features in a library myself (albeit a bit slower than the compiler could) if I am able to get a list of conforming types at runtime (and then call static methods on those types).
Also, if there is a way to do this now (even if it is slow), I would appreciate the help…
On Nov 15, 2016, at 19:53 , Jonathan Hull via swift-evolution <swift-evolution@swift.org> wrote:
I would like to be able to get, at runtime, an array of all types conforming to a particular protocol. (Similarly, I would like to be able to get an array of all subtypes of a given type). Is this in the generics manifesto? If not, can it be added? What is the timeframe?
It seems to me, that the compiler should actually already have this information, and it is just a matter of keeping it around when it is requested. I could be wrong about that though...
Why do I want this? It would make a lot of things like plug-ins and extensible factories possible (and much easier where they are possible). For example, you could add a new type to a factory (without the factory having to be coupled to it) just by adhering to a protocol. It would also make building a swift version of NSCoding much easier.
I have asked for other, more complicated, language features (e.g. handler funcs) to make those possible before, and I still want them (since I have used them in other languages and it was enormously powerful), but I realized that I should actually be able to make most of those features in a library myself (albeit a bit slower than the compiler could) if I am able to get a list of conforming types at runtime (and then call static methods on those types).
Also, if there is a way to do this now (even if it is slow), I would appreciate the help…
I would like to be able to get, at runtime, an array of all types conforming to a particular protocol. (Similarly, I would like to be able to get an array of all subtypes of a given type). Is this in the generics manifesto? If not, can it be added? What is the timeframe?
It seems to me, that the compiler should actually already have this information, and it is just a matter of keeping it around when it is requested. I could be wrong about that though...
The compiler does not have sufficient information to do this. Dynamic libraries and resilience can add new protocol-conforming types and new protocol-conformaning extensions to existing types.
This sort of search could be implemented by the runtime, but it would likely be slow and memory-hungry. The Swift runtime wants to be as lazy as possible about type metadata, in order to reduce launch time and memory footprint. Any operation that requires inspecting every type in every library will defeat this laziness.
Also, if there is a way to do this now (even if it is slow), I would appreciate the help…
The existing protocol conformance metadata might be sufficient to do this, but I don't think there is any runtime affordance to query it this way.
···
On Nov 15, 2016, at 7:53 PM, Jonathan Hull via swift-evolution <swift-evolution@swift.org> wrote: