Where can I find a link to an updated version? > On 19 Feb 2017, at 21:42, Adrian Zubarev via swift-evolution > <[email protected]> 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 > ([email protected] <mailto:[email protected]>) > 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 >> ([email protected] <mailto:[email protected]>) >> 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 ([email protected] >>> <mailto:[email protected]>) 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 <[email protected] >>>> <mailto:[email protected]>>: >>>> >>>> >>>> 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 > [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
