This isn’t a full proposal (yet). We still can change things. I didn’t consider
everything and can’t to that on my own. Feedback is welcome.
To answer your question, we still need the metatype to access initializer and
static member of that type. If we’d drop T.Type completely, we’d lose
functionality to do so.
protocol A {
init()
}
func foo<T : A>(metatype: T.Type) -> T {
return metatype.init()
}
The downside of this proposal is the bottleneck property to access that
functionality, otherwise adding Hashable or other things like size
(MemoryLayout) won’t be possible without serious compiler magic. So do I
believe.
func foo<T : A>(type: Type<T>) -> T {
return type.metatype.init()
}
This is huge tradeoff, but it’s worth considering if the community can life
with that.
Furthermore as already been mentioned in this thread, we might consider to
extend Type<T> to add reflection functionality to it. (If we’d decide to go in
that direction.)
--
Adrian Zubarev
Sent with Airmail
Am 13. Juli 2016 um 13:15:02, Anton Zhilin ([email protected]) schrieb:
Why can't we drop metatypes T.Type with your proposal? Do they bring some extra
capabilities over Type<T> struct?
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
