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

[Anton Zhilin]

I will now talk about general design, not specific methods or
implementation details. This touches SE-0101.

The following are niches for metatype-like types:

   1. Explicit specialization of functions and expressing specific static
   types
   2. Dynamic dispatch of static methods
   3. Passing around information about dynamic type; reflection
   4. Container for size, stride, alignment

Basic thoughs on each of them (trying to be objective!):

   1. We must have a generic type. Even struct Type<T> { } would be enough
   (I’m not suggesting it). Current T.Type can also do that
   2. Only metatypes (current T.Type) can do that
   3. Is best expressed using a non-generic type like Mirror
   4. Can be dropped on top of metatypes (global functions), or Mirror
   (properties plus global functions) or whatever custom type (properties).

So, we give (2) to metatypes, because we must do so, and give (3) to Mirror.
Now to opinionated side. The following are solutions I could come up with:

   1. Current state of things
      - Metatypes do (1)
      - Global functions on metatypes do (4)
      - Pro No extra entities, just metatypes and Mirror
      - Pro Functions on metatypes are not perfect, but they are “good
      enough”
      - Con Mixed static type instances and metatypes. Value of passed
      metatypes is often ignored
      - Con Some people hate global functions (although they are right
      solution for “methods of metatypes”)
   2. Proposal of this thread; Type<T> struct
      - Type<T> is a wrapper for metatypes
      - The shortest syntax (.self and type literals) is passed from
      metatypes to Type<T>
      - Type<T> does (1) and (4)
      - Pro Groups of size, stride, alignment in a logical context
      - Con Again, mixed static type instances and Type<T>
      - Con Additional entity Type<T>
      - Con Type<T> partially takes work of Mirror (dynamic size, stride,
      align)
   3. MemoryLayout proposal
      - Metatypes do (1)
      - MemoryLayout<T> contains size, stride, alignment
      - Con Again, mixed static type instances and metatypes
      - Con Additional MemoryLayout entity, which only hosts 3 functions
      - Con MemoryLayout<T> is not able to get size of dynamicType by design
   4. My suggestion #1
      - Allow labelless initialization of Mirror from metatype or from value
      - Move dynamic size, stride, alignment to Mirror
      - Leave static size, stride, alignment as global functions
      - Pro Does not introduce new entities
      - Pro I feel like this is the perfect place for dynamic size, stride,
      alignment
      - Con Again, mixed static type instances and metatypes
      - Con Global functions. I’m fine with them, but some people don’t
      like them
   5. My suggestion #2
      - Allow labelless initialization of Mirror from metatype or from value
      - Move dynamic size, stride, alignment to Mirror
      - T.self and future type literals will create instances of Type<T>

struct Type<T> {
    init()

    var size: Int { return sizeof(T.self) }
    var stride: Int { return strideof(T.self) }
    var alignment: Int { return alignof(T.self) }
    static var size: Int { return sizeof(T.self) }
    static var stride: Int { return strideof(T.self) }
    static var alignment: Int { return alignof(T.self) }

    var metatype: Metatype<T> { return T.metatype }
    static var metatype: Metatype<T> { return T.metatype }

    // Nothing more; no fields!
}


   - Metatypes will be typically created using Type<T>.metatype and
   dynamicType
   - Pro Both static and dynamic size, stride, alignment are in logically
   suited contexts
   - Pro Metatypes (with which few people will work) are separated from
   static types (which are used for function specialization etc)
   - Con Additional entity Type<T>, but I think it’s the most elegant of
   all solutions that introduce additional types

I will prepare a separate proposal with this last option.
​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160716/f8d6a3f8/attachment.html>