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

[Adrian Zubarev]

As I stated my current position in some of my last posts:

Originally I wanted to disallow T.Type in declarations - BUT I CHANGED MY MIND :)

We should keep metatypes :)

To get an instance of a metatype I’d prefer this usage Type<T>.metatype or Type<T>().metatype or:

let type = Int // Type<Int>
type.metatype
We’d want to drop public .self and produce an instance of Type<T> from T, when T is passed around or stored (no implicit conversion in declarations)

That should solve the ambiguity in array/dictionary shorthand syntaxes

final class is fine and optimizes the api

I’d rename internal .self to .metatype so we still can get the metatype internally.

I’d rename T.Type to T.Metatype and produce typealias Metatype<T> = T.Metatype

Furthermore T.Metatype would be disallowed in declarations for the sake of Metatype<T>

Metatype functionality will remain as is, but we make some ground renaming and how we’d access/instantiate a metatype.

That said Type<T> should help solving SE–0090, combine SE-0101, provide an implementation structure for SE–0096, and make the first step into reflections. Furthermore Type<T> would be a breaking change which we should consider now.



-- 
Adrian Zubarev
Sent with Airmail

Am 15. Juli 2016 um 08:25:40, Brent Royal-Gordon (brent at architechies.com) schrieb:

I like the `Type<>` syntax, especially if it's something that could at least partially be written in the standard library (how nice would it be if we had `final class Type<Describing>` in the generated headers?), and I really like the idea of extending a metatype to conform to a protocol. But a lot of what's being discussed here, I just don't get. What's the benefit of switching to structs? Of removing type members? 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160715/78b9ec6e/attachment.html>