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

Adrian Zubarev adrian.zubarev at devandartist.com
Fri Jul 15 15:02:17 CDT 2016


I haven’t noticed the difference between those to at first glance.

Okay but do we need public initializer at all?

I’d put this into the alternative section so the core team can decide how to implement it (if this gets accepted).

I’ll prepare a second implementation gist for this suggestion. Feel free to update the proposal for both versions. (I see what you meant - COW optimized type like Foundation types.)

I’m to tired right now, I’ll do it tomorrow. It seems that we’re almost there. Maybe we can PR tomorrow so the review will kick off ASAP.



-- 
Adrian Zubarev
Sent with Airmail

Am 15. Juli 2016 um 21:49:29, Anton Zhilin (antonyzhilin at gmail.com) schrieb:

I suggested it because now we can’t call any initializers on  
Type<T>. If we add  
_Type<T>, we can add public initializers and keep  
Type<T> instances unique.

// No uniqueness guarantee
internal final class _Type<T> {
    var _metatype: Metatype<T>

    init()
    init(_: AnyMetatype)
    init?<U>(casting: Type<U>)
}

internal var _typeStorage = Set<_Type<Any>>()

// Uniqueness guarantee
// 'final class' is an implementation detail
public struct Type<T> {
    internal var _impl: _Type<T>

    // Notice 'public'
    public init()
    public init(_: AnyMetatype)
    public init?<U>(casting: Type<U>)
}
There will be no  
=== operator for  
Type<T>, because it does not add value.  
Type<T> is a wrapper of typeless identifier with value semantics. It is singleton pattern that makes us use classes.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160715/931d21ad/attachment.html>


More information about the swift-evolution mailing list