> On Jul 8, 2016, at 1:06 PM, Adrian Zubarev via swift-evolution
> <[email protected]> wrote:
>
> Hello Swift community, before Swift 3 drops I’d like to discuss if it is
> reasonable to consider to create a standalone type to drop/seal the T.Type
> magic?
>
Hi Adrian,
What’s the motivation for this change?
-Chris
> However this change does not play well with the proposal of dropping the
> .self compiler magic.
>
> Some bikeshedding:
>
> public struct Type<T> : Hashable {
>
> // Seal the `.Type` magic into this standalone type.
> // Disallow `.Type` usage elsewhere
>
> public let sealed: T.Type
>
> public var hashValue: Int { /* implement somehow */ }
>
> public init() {
>
> // Or do it somehow different for the sake of dropping `.self` magic
> self.sealed = T.self
> }
> }
>
> public func ==<T>(lhs: Type<T>, rhs: Type<T>) -> Bool {
>
> return lhs.hashValue == rhs.hashValue
> }
> Downside of this approach is the accessibility of the .Type instance:
>
> protocol Initializable {
> init()
> }
>
> func foo<T : Initializable>(type: Type<T>) -> T {
>
> // It would be nice if we could use `type.init()` instead, but than we
> // would need more compiler magic :/
> return type.sealed.init()
> }
> I couldn’t come up with a better name than sealed, if anyone has a better
> idea feel free to share your thoughts.
>
> Remember this is a discussion and not (yet) a detailed proposal, where
> everyone can provide feedback and bikeshedding for a better design.
>
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> _______________________________________________
> swift-evolution mailing list
> [email protected] <mailto:[email protected]>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
