[swift-evolution] [Pitch] Refactor Metatypes

[Adrian Zubarev]

https://github.com/DevAndArtist/swift-evolution/blob/metatypes/proposals/0126-refactor-metatypes.md


-- 
Adrian Zubarev
Sent with Airmail

Am 19. Februar 2017 um 22:59:18, David Hart (david at hartbit.com) schrieb:

Where can I find a link to an updated version?

On 19 Feb 2017, at 21:42, Adrian Zubarev via swift-evolution <swift-evolution at swift.org> wrote:

We added a note to the proposal:

Both Type<T> and AnyType<T> will be declared in the Swift standard library even if part of the implementation might be compiler magic. That move is really important to allow developers to created custom nested types named as Type. ModuleName.TypeName.Type is ambigious today, but will become possible after this proposal. That means Type<T> and AnyType<T> will be shortcuts for Swift.Type<T> and Swift.AnyType<T>.
We also think that the proposal is ready for the review. :)




-- 
Adrian Zubarev
Sent with Airmail

Am 19. Februar 2017 um 09:40:19, Adrian Zubarev (adrian.zubarev at devandartist.com) schrieb:

Actually Brent has just now convinced me that Metatype would be a bad name to choose. So forget what I said in my last messages.



-- 
Adrian Zubarev
Sent with Airmail

Am 18. Februar 2017 um 17:55:33, Adrian Zubarev (adrian.zubarev at devandartist.com) schrieb:

The problem I was describing is about nested types named .Type, indeed. Assuming the proposal would go with Type<T>, then it means you _might_ be able to create nested types called Type, but you always would need to call if through the whole namespace (e.g. A.B.Type). That is a huge downside.

Metatype on the other hand describes exactly what that _thing_ really is.

Currently on a different branch I added this important note to the alternatives, but I’d rather use these types for the whole proposal.

Assuming that the accepted proposal decides to use Metatype<T>, AnyMetatype<T> over Type<T> and AnyType<T> would imply that the type Type would no longer be ambiguous to use in custome modules. However, such naming choice will affect the type(of:) function. It might be necessary to align the function name to metatype(of:) to avoid any confusion, which will result in another breaking change. Alternatively we could leave the function as func type<T>(of instance: T) -> AnyMetatype<T>.
If we’re going for breaking changes again than I’d prefer to align the magical type(of:) function to metatype(of:).

I’d love to hear more input on this.



-- 
Adrian Zubarev
Sent with Airmail

Am 18. Februar 2017 um 17:00:27, Anton Zhilin (antonyzhilin at gmail.com) schrieb:

Type is a bad name for a public type: FooType is almost always a better name. Libraries that describe “just types”, Swift types, can as well use Metatype or Mirror or something.
For nested types, like Foo.Type, in the meaning of “type of Foo“, Type can’t be used even now.
I’d give up on Type name for the greater future of metatypes.

2017-02-18 16:28 GMT+03:00 Adrian Zubarev <adrian.zubarev at devandartist.com>:


Personally I’d prefer Metatype<T> and AnyMetatype<T> to get rid of the restriction where you mostly cannot create custom types called Type, which annoys me a lot. Sometimes Kind as a good workaround but there are times where Kind doesn’t fit. :/



_______________________________________________
swift-evolution mailing list
swift-evolution at swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170219/246380e1/attachment.html>