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

[Adrian Zubarev]

Okay I carefully read the gist and here is my feedback:

First of all thank you for combining your thoughts with mine.

There is a small typo (SE–0090 is not accepted yet) - only in the first example:

func unsafeBitCast<T, U>(_: T, to: U.Type)
unsafeBitCast(10, to: Double)
     
// The second line should be
unsafeBitCast(10, to: Double.self)
Size and internal structure of Type will be the same as of T.Type
Do we really need this to be the same?
Values of Type store identifiers of U such that U: T.
Why would we want to store more than one unique identifier?
Actually I thought for a while about the negative effect of fully removing metatypes from the language. Metatypes allow us to build neat looking execution branches like showed in SE–0101.

extension MemoryLayout<T> {
    init(_ : @autoclosure () -> T) {}
    public static func of(_ candidate : @autoclosure () -> T) -> MemoryLayout<T>.Type {
        return MemoryLayout.init(candidate).dynamicType
    }
}

// Value
let x: UInt8 = 5
MemoryLayout.of(x).size // 1
MemoryLayout.of(1).size // 8
MemoryLayout.of("hello").stride // 24
MemoryLayout.of(29.2).alignment // 8
I wouldn’t want to throw this away.

I played with the idea of keeping T.Type internally but disallow it in public declarations. Furthermore metatypes would still exist, but can only be instantiated through Type<T>.metatype or Type<T>().metatype.

To keep the neat designing feature but get rid of T.Type we could abuse generic typealiases here:

// T.Type would be only visible here but is disallowed in public declarations
// in favor of `Metatype<T>`
public typealias Metatype<T> = T.Type

public struct Type<T> : Hashable, CustomStringConvertible, CustomDebugStringConvertible {

    …
    public var metatype: Metatype<T> { return Type<T>.metatype }
     
    // Internally `.self` should be renamed to `.metatype` and return
    // a metatype instance  
    public static var metatype: Metatype<T> { return T.metatype }
    …
}
That way the sample from above won’t break from its designing point, but will require some refactoring:

extension MemoryLayout<T> {
    init(_ : @autoclosure () -> T) {}
    public static func of(_ candidate : @autoclosure () -> T) -> Metatype<MemoryLayout<T>> {
        return dynamicType(MemoryLayout.init(candidate)).metatype
    }
}
I’m aware that we are moving size etc. into Type but the example I just used was to show that metatypes are still very useful in terms of designing neat looking apis.

That’s why I’d suggest that our proposal should tackle solving SE–0090, opening the door for reflections, combining SE–0101 and providing an easier implementation for SE–0096.

Internally the core team might rename T.Type to T.Metatype to sort out any confusion. And we still would migrate all public T.Type to use Type<T> instead.

PS:

We should also mention that dynamic casts need some tweaking to work with Type<T>.

And one more thing:

public var size: Int      { get }
public var stride: Int    { get }
public var alignment: Int { get }

public static var size: Int      { return Type<T>().size }
public static var stride: Int    { return Type<T>().stride }
public static var alignment: Int { return Type<T>().alignment }
Shouldn’t these work exactly the opposite way? If in the future Type<T> would be extended with reflection functionality and contain more stored properties, it would be lightweight to compute size etc. from static size without the need of instantiating the whole type.

public var size: Int      { return Type<T>.size  }
public var stride: Int    { return Type<T>.stride }
public var alignment: Int { return Type<T>.alignment }

public static var size: Int      { get }
public static var stride: Int    { get }
public static var alignment: Int { get }


-- 
Adrian Zubarev
Sent with Airmail

Am 14. Juli 2016 um 12:39:05, Anton Zhilin (antonyzhilin at gmail.com) schrieb:

Plase take a look:
https://gist.github.com/Anton3/08a069a3b6f634bece7ad666922741d2

2016-07-14 0:38 GMT+03:00 Adrian Zubarev via swift-evolution <swift-evolution at swift.org>:
I’m still not fully convinced about fully removing the access to the metatype.

If you look at Ericas and Daves current proposal for MemoryLayout it would completely break and it would become impossible to build something like this.

And yes I borrowed the idea of putting properties like size into Type<T> from SE–0101. That was mentioned in my previews posts.

If we remove .Type, how’d we access static members in other types like MemoryLayout<T>?

This is another contra argument to consider.
@Erica @Dave: Any statement on our conversation about Type<T>?

I apologize that this whole idea raised in parallel to your proposal.

PS: We can merge our ideas into a single formal proposal. Ping me off-list when you get some time tomorrow.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160714/736466fd/attachment.html>