[swift-evolution] [Discussion] Seal `T.Type` into `Type<T>`

Adrian Zubarev adrian.zubarev at devandartist.com
Fri Jul 15 10:21:40 CDT 2016


I’m investing all my strength to create such a design. Stay patient and feel free to provide feedback to the our vision of the implementation (WIP): https://gist.github.com/DevAndArtist/a5744f21107812b2d4e6baee2c55e0bf



-- 
Adrian Zubarev
Sent with Airmail

Am 15. Juli 2016 um 17:17:44, L. Mihalkovic (laurent.mihalkovic at gmail.com) schrieb:


Regards
LM
(From mobile)

On Jul 13, 2016, at 2:02 PM, Adrian Zubarev via swift-evolution <swift-evolution at swift.org> wrote:

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.)

IMHO it is not just a matter of 'adding reflection'.. this IS a subset of reflection. The key is to design it question exhaustively enough to leave clean holes for the rest being only additive. Otherwise this will lead the way to more 'oops we have to change the proposal so that what we loose now can be put back additively later' (reference to the recent dance around the labels in sigs proposal that had to be patched post-acceptance)




-- 
Adrian Zubarev
Sent with Airmail

Am 13. Juli 2016 um 13:15:02, Anton Zhilin (antonyzhilin at gmail.com) 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
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/20160715/e812745b/attachment.html>


More information about the swift-evolution mailing list