Re: [swift-evolution] [Pitch] Refactor Metatypes

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 (da...@hartbit.com) schrieb: Where can I find a link to an updated version? On 19 Feb 2017, at 21:42, Adrian

Re: [swift-evolution] [Pitch] Refactor Metatypes

Where can I find a link to an updated version? > On 19 Feb 2017, at 21:42, Adrian Zubarev via swift-evolution > wrote: > > We added a note to the proposal: > > Both Type and AnyType will be declared in the Swift standard library > even if part of the implementation

Re: [swift-evolution] [Pitch] Refactor Metatypes

We added a note to the proposal: Both Type and AnyType 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

Re: [swift-evolution] [Pitch] Refactor Metatypes

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.zuba...@devandartist.com) schrieb: The problem I was describing is

Re: [swift-evolution] [Pitch] Refactor Metatypes

The problem I was describing is about nested types named .Type, indeed. Assuming the proposal would go with Type, 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.

Re: [swift-evolution] [Pitch] Refactor Metatypes

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

Re: [swift-evolution] [Pitch] Refactor Metatypes

Personally I’d prefer Metatype and AnyMetatype 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. :/ --  Adrian Zubarev Sent with Airmail Am 18. Februar

Re: [swift-evolution] [Pitch] Refactor Metatypes

Personally I’d like a shortcut like AnyType, but it won’t work as a typealias, because it will create a circle reference between AnyType and AnyType. However, there is a small possibility that this type might be generalized like Any (now possibly AnyObject) directly into the language. That

Re: [swift-evolution] [Pitch] Refactor Metatypes

I guess, now is the time? The response on this has been positive, both for the new metatype syntax and separation of static and dynamic metatypes. I’ve got one more feature in mind since then—a shorthand of AnyType ≡ AnyType. Would this addition be worth extra syntax? Is it feasible from current

Re: [swift-evolution] [Pitch] Refactor Metatypes

> On Jan 20, 2017, at 12:37 PM, Anton Zhilin via swift-evolution > wrote: > > Could someone tell if the proposal fits Phase 1? Seeing SE-0148—which doesn't > contain any ABI-breaking changes—being reviewed for Phase 1, I'm not sure > about anything. > The PR should

Re: [swift-evolution] [Pitch] Refactor Metatypes

Is there a need of having this function at all? You always know the current static type locally. Sure one might need this in some generic function to extract the static type from an instance, but most of the time we could just write T.self to do that. If there really is a need for that

Re: [swift-evolution] [Pitch] Refactor Metatypes

> On Oct 11, 2016, at 12:26 AM, Adrian Zubarev via swift-evolution > wrote: > > This is the latest draft of the proposal: > https://github.com/DevAndArtist/swift-evolution/blob/refactor_existential_metatypes/proposals/0126-refactor-metatypes.md > >

Re: [swift-evolution] [Pitch] Refactor Metatypes

This is the latest draft of the proposal: https://github.com/DevAndArtist/swift-evolution/blob/refactor_existential_metatypes/proposals/0126-refactor-metatypes.md Refactor Metatypes Proposal: SE–0126 Authors: Adrian Zubarev, Anton Zhilin, Brent Royal-Gordon Status: Revision Review manager:

Re: [swift-evolution] [Pitch] Refactor Metatypes

Ups sorry. Found the mistake. Done. --  Adrian Zubarev Sent with Airmail Am 2. Oktober 2016 um 17:40:47, Adrian Zubarev (adrian.zuba...@devandartist.com) schrieb: I don’t understand. I renamed Subtype with AnyType everywhere and mentioned it in Alternatives considered section.

Re: [swift-evolution] [Pitch] Refactor Metatypes

I’d say that subtype is correct there. As mentioned by some people here subtype feels like it has something to do with classes. Assume this: class Base { init() {...} } class A : Base {} let subtype: AnyType = subtype(of: Base.self, named: "A")! // One day when `.self` magic is gone

Re: [swift-evolution] [Pitch] Refactor Metatypes

You can read the updated version of the proposal on a sub-branch: https://github.com/DevAndArtist/swift-evolution/blob/refactor_existential_metatypes/proposals/0126-refactor-metatypes.md --  Adrian Zubarev Sent with Airmail Am 2. Oktober 2016 um 11:47:50, Goffredo Marocchi (pana...@gmail.com)

Re: [swift-evolution] [Pitch] Refactor Metatypes

Love it :)! Sent from my iPhone > On 2 Oct 2016, at 09:37, Adrian Zubarev via swift-evolution > wrote: > > That’s right. I was about to say something similar about the Of. > > Actually Type would be the correct name for the static/concrete metatype. > > We already

Re: [swift-evolution] [Pitch] Refactor Metatypes

That sounds very good to me, and AnyType aligns well with the proposed Any<...> syntax. — Pyry > Adrian Zubarev wrote: > > That’s right. I was about to say something similar about the Of. > > Actually Type would be the correct name for the static/concrete metatype. > > We already have this

Re: [swift-evolution] [Pitch] Refactor Metatypes

That’s right. I was about to say something similar about the Of. Actually Type would be the correct name for the static/concrete metatype. We already have this notation but not in a generic way T.Type If we add of only in our mind to Type, we’ll get “Type of a type T” which is shortly referred

Re: [swift-evolution] [Pitch] Refactor Metatypes

> Goffredo Marocchi wrote: > > I think the names should be bikeshedded more still. From your examples they > seem to make sense when I mentally add Of like TypeOf<> and SubTypeOf<>, but > since you are not commenting on why that is wrong or right or misleading, or > at least I have missed

Re: [swift-evolution] [Pitch] Refactor Metatypes

I think the names should be bikeshedded more still. From your examples they seem to make sense when I mentally add Of like TypeOf<> and SubTypeOf<>, but since you are not commenting on why that is wrong or right or misleading, or at least I have missed your reply on that, I am still a bit at

Re: [swift-evolution] [Pitch] Refactor Metatypes

> On Sep 30, 2016, at 10:25 PM, Russ Bishop wrote: > This topic is confusing enough that I think it warrants being extremely clear > about the naming. Type and Subtype feel like a class hierarchy and that’s not > exactly what we are doing here. If Type represents the static

Re: [swift-evolution] [Pitch] Refactor Metatypes

> On Sep 29, 2016, at 7:29 PM, Brent Royal-Gordon > wrote: > >> On Sep 29, 2016, at 3:24 PM, Russ Bishop via swift-evolution >> wrote: >> >> Why would we not have type(of:) and subtype(of:)? Why would I want the >> Subtype instead of the

Re: [swift-evolution] [Pitch] Refactor Metatypes

On Fri, Sep 30, 2016 at 5:56 PM, Brent Royal-Gordon wrote: > > On Sep 29, 2016, at 9:21 PM, Xiaodi Wu wrote: > > > > Can you elaborate on your two reasons for the proposed Type? > > > > In particular, what do you mean by inheritable and

Re: [swift-evolution] [Pitch] Refactor Metatypes

> On Sep 29, 2016, at 9:21 PM, Xiaodi Wu wrote: > > Can you elaborate on your two reasons for the proposed Type? > > In particular, what do you mean by inheritable and non-inheritable members of > T? Where do these come into play? How is the current T.Type deficient in

Re: [swift-evolution] [Pitch] Refactor Metatypes

I replied on your gist directly, but you can also read my reply below. I though I made it crystal clear in my last post what the main problem is. Again: T.Type serves two jobs at once. It’s a concrete metatype of T. It’s an existential metatype of T where other metatypes where U is a subtype

Re: [swift-evolution] [Pitch] Refactor Metatypes

2016-09-30 22:48 GMT+03:00 Xiaodi Wu via swift-evolution < swift-evolution@swift.org>: Sorry, my question at least has nothing to do with bikeshedding. I'm > confused about why the proposal feels it's necessary to have both Type and > Subtype. I don't understand Brent's two reasons and was hoping

Re: [swift-evolution] [Pitch] Refactor Metatypes

Sorry, my question at least has nothing to do with bikeshedding. I'm confused about why the proposal feels it's necessary to have both Type and Subtype. I don't understand Brent's two reasons and was hoping for some elaboration. I've tried to clarify my question in a gist:

Re: [swift-evolution] [Pitch] Refactor Metatypes

About the proposed names: To be crystal clear we could use more descriptive names for our two types. Today T.Type is referred as *metatype* and serving two different purposes at once. It’s a concrete type; we call it Type or other suggested names looked like ExactType, StaticType etc. T.Type

Re: [swift-evolution] [Pitch] Refactor Metatypes

I’ll join the conversation tomorrow. Thanks to Brent for his huge contribution. :) Just a quick side note: Moving from T.Type and T.Protocol to Type and Subtype would also allow us to finally reuse and correctly nest our custom Type and Protocol types. struct A { struct Type {} } A.Type()

Re: [swift-evolution] [Pitch] Refactor Metatypes

Hey Brent, Sorry for being a bit dense about this, but... > >NSObject >NSResponder: NSObject >NSView: NSResponder > > `Type` is a `Subtype`, but not a `Subtype`. > > Thus, this reads correctly: > >let aType: Subtype = NSView.self > > Whereas this does not: > >let aType:

Re: [swift-evolution] [Pitch] Refactor Metatypes

Great explanation. Can you elaborate on your two reasons for the proposed Type? In particular, what do you mean by inheritable and non-inheritable members of T? Where do these come into play? How is the current T.Type deficient in this respect? Regarding (2), it is already possible to do

Re: [swift-evolution] [Pitch] Refactor Metatypes

> On Sep 29, 2016, at 8:14 PM, Xiaodi Wu via swift-evolution > wrote: > > I'm confused by this explanation.Today, `type(of:)` is the new > `.dynamicType`. Is this proposal suggesting a silent change so that it now > returns the static type? If so, why (particularly

Re: [swift-evolution] [Pitch] Refactor Metatypes

I'm confused by this explanation.Today, `type(of:)` is the new `.dynamicType`. Is this proposal suggesting a silent change so that it now returns the static type? If so, why (particularly when you explain that this is often *not* what you would want)? I'm also somewhat puzzled about the proposed

Re: [swift-evolution] [Pitch] Refactor Metatypes

>From Brent’s explanation, it sounds to me like “Type” and “StaticType” respectively would be more descriptive than “Subtype” and “Type” as proposed. Nevin On Thu, Sep 29, 2016 at 10:29 PM, Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote: > > On Sep 29, 2016, at 3:24

Re: [swift-evolution] [Pitch] Refactor Metatypes

> On Sep 29, 2016, at 3:24 PM, Russ Bishop via swift-evolution > wrote: > > Why would we not have type(of:) and subtype(of:)? Why would I want the > Subtype instead of the specific Type? Let's turn this around. Suppose you write: let obj: NSObject = …

Re: [swift-evolution] [Pitch] Refactor Metatypes

> On Sep 28, 2016, at 3:18 AM, Adrian Zubarev via swift-evolution > wrote: > > func unsafeBitCast(_: T, to type: Type) -> U > func ==(t0: Subtype?, t1: Subtype?) -> Bool > func type(of: T) -> Subtype // SE-0096 > That last example, type(of:), is rather

Re: [swift-evolution] [Pitch] Refactor Metatypes

2016-09-29 3:31 GMT+03:00 Colin Barrett via swift-evolution < swift-evolution@swift.org>: >- > >Type is the concrete type of T.self. A Type only ever has one >instance, T.self; even if T has a subtype U, Type is not a subtype >of Type. >- > >Subtype is the supertype of

Re: [swift-evolution] [Pitch] Refactor Metatypes

First off, I agree with Nevin (up-thread) that this is a much clearer version of the previous proposal, well done. > On Sep 28, 2016, at 6:18 AM, Adrian Zubarev via swift-evolution > wrote: > > Formatted version: >

Re: [swift-evolution] [Pitch] Refactor Metatypes

Let me first say that this new draft does a great job of explaining the current situation and the goals of the proposal. The revised “Motivation” section in particular is very clearly written and introduces the concepts effectively. I found the previous versions to be highly confusing, and I did