subject:"Re\: \[swift\-evolution\] \[Pitch\] Refactor Metatypes"

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

2017-02-19 Thread Adrian Zubarev via swift-evolution

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 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 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 and AnyType will be shortcuts for 
Swift.Type and Swift.AnyType.
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.zuba...@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.zuba...@devandartist.com) schrieb:

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.

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, AnyMetatype 
over Type and AnyType 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(of instance: 
T) -> AnyMetatype.
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 (antonyzhi...@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 :


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. :/



___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-02-19 Thread David Hart via swift-evolution

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 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 and AnyType will be shortcuts for 
> Swift.Type and Swift.AnyType.
> 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.zuba...@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.zuba...@devandartist.com ) 
>> schrieb:
>> 
>>> 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.
>>> 
>>> 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, 
>>> AnyMetatype over Type and AnyType 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(of instance: T) -> AnyMetatype.
>>> 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 (antonyzhi...@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 >:
 
 
 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. :/
 
 
>>> 
>> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-02-19 Thread Adrian Zubarev via swift-evolution

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 ambigious today, but will become possible after 
this proposal. That means Type and AnyType will be shortcuts for 
Swift.Type and Swift.AnyType.
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.zuba...@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.zuba...@devandartist.com) schrieb:

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.

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, AnyMetatype 
over Type and AnyType 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(of instance: 
T) -> AnyMetatype.
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 (antonyzhi...@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 :

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. :/

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-02-19 Thread Adrian Zubarev via swift-evolution

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 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.

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, AnyMetatype 
over Type and AnyType 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(of instance: 
T) -> AnyMetatype.
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 (antonyzhi...@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 :

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. :/

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-02-18 Thread Adrian Zubarev via swift-evolution

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.

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, AnyMetatype 
over Type and AnyType 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(of instance: 
T) -> AnyMetatype.
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 (antonyzhi...@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 :

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. :/

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-02-18 Thread Anton Zhilin via swift-evolution

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 :

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. :/
>

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-02-18 Thread Adrian Zubarev via swift-evolution

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 2017 um 10:20:14, Anton Zhilin (antonyzhi...@gmail.com) schrieb:

Yes,  
Any,  
AnyObject,  
AnyType would look nice together. But I’d suggest to do it separately and for 
now, try to push the main proposal for review.

2017-02-17 19:09 GMT+03:00 Adrian Zubarev :

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 would probably 
allow us to use AnyType as a shortcut to AnyType.

I’m not sure if this should be part of our proposal or not. I’d like to have 
some more feedback from the core team on this one.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-02-17 Thread Adrian Zubarev via swift-evolution

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 would probably 
allow us to use AnyType as a shortcut to AnyType.

I’m not sure if this should be part of our proposal or not. I’d like to have 
some more feedback from the core team on this one.



-- 
Adrian Zubarev
Sent with Airmail

Am 17. Februar 2017 um 14:24:14, Anton Zhilin (antonyzhi...@gmail.com) schrieb:

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 generics 
point of view? Anyway, it can be done in a separate proposal.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-02-17 Thread Anton Zhilin via swift-evolution

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
generics point of view? Anyway, it can be done in a separate proposal.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-01-20 Thread Douglas Gregor via swift-evolution

> 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 either be labeled "out of scope of current release", or merged. 
> Or maybe it contains some fundamental flaws that even prevent it from review?

SE-0148 fits in phase 1 because it’s in support of Phase 1 goals—specifically, 
it enables intended ABI-breaking changes in the standard library and is 
intended to be used as part of the String design.

AFAICT, the Refactoring Metatypes proposal is mostly independent. I view it as 
something that is important to look at in phase 2 because it is 
source-breaking, and if we’re going to do it, it should happen in Swift 4 
rather than Swift 5.

- Doug

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2016-10-13 Thread Adrian Zubarev via swift-evolution

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 function, we could move it to future talk 
when might want to add the following function to the language.

/// This function could find dynamically metatypes if they exist (even value 
types).
func type/subtype(of type: Type, named name: String) -> AnyType? { … }

protocol P { init() }
struct S : P { init() {} }

let struct: P = subtype(of: P.self, named: "S")!.init() // Neat
struct is S //=> true

// One day when `.self` magic is removed, we'd have this nice form.

let struct: P = subtype(of: P, named: "S")!.init() // Neat

// With the proposed metatype model we could even get the static metatypes for 
protocols

let protocolMetatype: AnyType = subtype(of: Any.self, named: "P")!
protocolMetatype is Type//=> true
protocolMetatype is AnyType //=> false
Again this is something for the future, but I felt like I had to mention it.

I’ll fix the typo, thanks.



-- 
Adrian Zubarev
Sent with Airmail

Am 13. Oktober 2016 um 07:09:04, Russ Bishop (xen...@gmail.com) schrieb:

Are we not going to have func staticType(of instance: T) -> Type ?

(Also you mis-spelled “instace”)



Overall I like it and the whole scheme brings some nice clarity.


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2016-10-12 Thread Russ Bishop via swift-evolution


> 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
>  
> 
> Refactor Metatypes
> 
> Proposal: SE–0126 
> 
> Authors: Adrian Zubarev , Anton Zhilin 
> , Brent Royal-Gordon 
> Status: Revision
> Review manager: Chris Lattner 
> Revision: 2
> Previous Revisions: 1 
> 
> In this new notation, some of our existing standard library functions would 
> have signatures like:
> 
> func unsafeBitCast(_: T, to type: Type) -> U
> func ==(t0: AnyType?, t1: AnyType?) -> Bool
> func type(of instace: T) -> AnyType // SE-0096
Are we not going to have func staticType(of instance: T) -> Type ?

(Also you mis-spelled “instace”)



Overall I like it and the whole scheme brings some nice clarity.


Russ



___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2016-10-11 Thread Adrian Zubarev via swift-evolution

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: Chris Lattner
Revision: 2
Previous Revisions: 1
Introduction

This proposal removes .Type and .Protocol in favor of two generic-style 
syntaxes and aligns global type(of:) function (SE–0096) to match the changes.

Swift-evolution thread (post Swift 3):

[Pitch] Refactor Metatypes
Older swift-evolution threads: [1], [2], [3]

Motivation

Every type T has an instance, accessible through T.self, which represents the 
type itself. Like all instances in Swift, this “type instance” itself has a 
type, which is referred to as its “metatype”. The metatype of T is written 
T.Type. The instance members of the metatype are the same as the static or 
class members of the type.

Metatypes have subtype relationships which reflect the types they represent. 
For instance, given these types:

protocol Proto {}
class Base {}
class Derived: Base, Proto {}
Derived.Type is a subtype of both Base.Type and Proto.Type (and Any.Type). That 
means that Derived.self can be used anywhere a Derived.Type, Base.Type, 
Proto.Type, or Any.Type is called for.

Unfortunately, this simple picture is complicated by protocols. Proto.self is 
actually of type Proto.Protocol, not type Proto.Type. This is necessary because 
the protocol does not, and cannot, conform to itself; it requires conforming 
types to provide static members, but it doesn’t actually provide those members 
itself. Proto.Type still exists, but it is the supertype of all types 
conforming to the protocol.

Making this worse, a generic type always uses T.Type to refer to the type of 
T.self. So when Proto is bound to a generic parameter P, P.Type is the same as 
Proto.Protocol.

This shifting of types is complicated and confusing; we seek to clean up this 
area.

We also believe that, in the long term, the dot syntax will prevent us from 
implementing certain future enhancements that might be valuable:

Moving the implementation of metatypes at least partly into the standard 
library.
Adding members available on all type instances for features like read-write 
reflection or memory layout information.
Conforming metatypes to protocols like Hashable or CustomStringConvertible.
Offering straightforward syntaxes for dynamic features like looking up types by 
name.
Proposed solution

We abolish .Type and .Protocol in favor of two generic-style syntaxes:

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.

AnyType is the supertype of all Types whose instances are subtypes of T, 
including T itself:

If T is a struct or enum, then Type is the only subtype of AnyType.

If T is a class, then Type and the Types of all subclasses of T are subtypes 
of AnyType.

If T is a protocol, then the Types of all concrete types conforming to T are 
subtypes of AnyType. Type is not itself a subtype of AnyType, or of 
any AnyType other than AnyType.

Structural types follow the subtype/supertype relationships of their 
constituent types. For instance:

Type<(NSString, NSString)> is a subtype of AnyType<(NSObject, NSObject)>

Metatypes of functions are a little bit more special (the subtyping relation on 
functions flips around for parameter types):

Type<(Any) -> Void> is a subtype of AnyType<(Int) -> Void> etc.
Type<(Void) -> Int> is a subtype of AnyType<(Void) -> Any>
In this new notation, some of our existing standard library functions would 
have signatures like:

func unsafeBitCast(_: T, to type: Type) -> U
func ==(t0: AnyType?, t1: AnyType?) -> Bool
func type(of instace: T) -> AnyType // SE-0096
That last example, type(of:), is rather interesting, because it is actually a 
magic syntax rather than a function. We propose to align this syntax with Type 
and AnyType by correcting the return type to AnyType. We believe this is 
clearer about both the type and meaning of the operation.

let anInstance: NSObject = NSString()
let aClass: AnyType = type(of: anInstance)

print(aClass) // => NSString
More details:

Every static or class member of T which can be called on all subtypes is an 
instance member of AnyType. That includes:

Static/class properties and methods

Required initializers (as methods named init)

Unbound instance methods

The Type of a concrete type T has all of the members required by AnyType, 
plus non-required initializers.

The Type of a protocol T includes only unbound instance methods of T.

If T conforms to P, then AnyType is a subtype of AnyType, even if T is a 
protocol.

The type of AnyType.self is Type.

The type of Type.self is Type, which is not a subtype of any type 
except AnyType. There is an infinite regress of Type<...>s.

AnyTypes are abstract types similar

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

2016-10-02 Thread Adrian Zubarev via swift-evolution

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.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2016-10-02 Thread Adrian Zubarev via swift-evolution

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
let subtype: AnyType = subtype(of: Base, named: "A")!
 
let a: Base = subtype.init()
 
print(type(of: a)) // => A
It’s clear that we’re working with classes here. type(of:named:) seems odd to 
me and doesn’t fit here at all.

Any more feedback?

Waiting for Brent to reply. I can’t remember what Subprotocol was for. 
That’s the reason why it looks like this for the moment. ;)

I don’t understand. I renamed Subtype with AnyType everywhere and mentioned it 
in Alternatives considered section.

I’d like to wait for more feedback, we’re not in rush now.



-- 
Adrian Zubarev
Sent with Airmail

Am 2. Oktober 2016 um 16:46:18, Anton Zhilin (antonyzhi...@gmail.com) schrieb:

I’m happy that everyone seems to agree on the new naming, and I also like that  
type function is back.

Some fixes:

In Future directions, replace  
subtype with  
type
In Future directions, remove overstruck last item
In Alternatives considered, replace the naming and add old naming to 
alternative options
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2016-10-02 Thread Adrian Zubarev via swift-evolution

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) schrieb:

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 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 as a “metatype of T”. (Array - Array of Element type)
Since Subtype in reality is some *existential metatype* and the whole talk 
about existential types now tend to have the Any prefix, lets follow that trend 
here too.

Type - (static/concrete/exact) metatype.
AnyType - existential metatype.
It might be even easier to memorise this name than Subtype.

The example from the proposal rewritten:

// Types:
protocol Foo {}
protocol Boo : Foo {}
class A : Foo {}
class B : A, Boo {}
struct S : Foo {}

// Metatypes:
let a1: Type = A.self   //=> Okay
let p1: Type = Foo.self   //=> Okay
let p2: Type = C.self //=> Error -- `C` is not the same as `Foo`

let any_1: AnyType = A.self   //=> Okay
let any_2: AnyType = Foo.self //=> Okay

let a_1: AnyType = A.self   //=> Okay
let p_1: AnyType = A.self //=> Okay
let p_2: AnyType = Foo.self   //=> Error -- `Type` is not a subtype 
of `AnyType`

// Generic functions:
func dynamic(type: AnyType, `is` _: Type) -> Bool {
  return type is AnyType
}

func dynamic(type: AnyType, `as` _: Type) -> AnyType? {
  return type as? AnyType
}

let s1: Type = S.self

dynamic(type: s1, is: Foo.self)//=> true
dynamic(type: s1, as: Foo.self)//=> an `Optional`
The type(of:) function could now stay, because now we’d only need to change the 
return type.

func type(of instance: T) -> AnyType
Isn’t this a good compromise?



-- 
Adrian Zubarev
Sent with Airmail

Am 2. Oktober 2016 um 09:01:45, Pyry Jahkola via swift-evolution 
(swift-evolution@swift.org) schrieb:

OTOH, we don't have ArrayOf or DictionaryOfKeyAndValue, 
while we still pronounce them that way. I don't think prepositions belong in 
the name of types but in exceptional cases, and this doesn't sound exceptional 
enough to me.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2016-10-02 Thread Goffredo Marocchi via swift-evolution

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 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 as a “metatype of T”. (Array - Array of Element 
> type)
> Since Subtype in reality is some *existential metatype* and the whole talk 
> about existential types now tend to have the Any prefix, lets follow that 
> trend here too.
> 
> Type - (static/concrete/exact) metatype.
> AnyType - existential metatype.
> It might be even easier to memorise this name than Subtype.
> 
> The example from the proposal rewritten:
> 
> // Types:
> protocol Foo {}
> protocol Boo : Foo {}
> class A : Foo {}
> class B : A, Boo {}
> struct S : Foo {}
> 
> // Metatypes:
> let a1: Type = A.self   //=> Okay
> let p1: Type = Foo.self   //=> Okay
> let p2: Type = C.self //=> Error -- `C` is not the same as `Foo`
> 
> let any_1: AnyType = A.self   //=> Okay
> let any_2: AnyType = Foo.self //=> Okay
> 
> let a_1: AnyType = A.self   //=> Okay
> let p_1: AnyType = A.self //=> Okay
> let p_2: AnyType = Foo.self   //=> Error -- `Type` is not a subtype 
> of `AnyType`
> 
> // Generic functions:
> func dynamic(type: AnyType, `is` _: Type) -> Bool {
>   return type is AnyType
> }
> 
> func dynamic(type: AnyType, `as` _: Type) -> AnyType? {
>   return type as? AnyType
> }
> 
> let s1: Type = S.self
> 
> dynamic(type: s1, is: Foo.self)//=> true
> dynamic(type: s1, as: Foo.self)//=> an `Optional`
> The type(of:) function could now stay, because now we’d only need to change 
> the return type.
> 
> func type(of instance: T) -> AnyType
> Isn’t this a good compromise?
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 2. Oktober 2016 um 09:01:45, Pyry Jahkola via swift-evolution 
> (swift-evolution@swift.org) schrieb:
> 
>> OTOH, we don't have ArrayOf or DictionaryOfKeyAndValue, 
>> while we still pronounce them that way. I don't think prepositions belong in 
>> the name of types but in exceptional cases, and this doesn't sound 
>> exceptional enough to me.
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2016-10-02 Thread Pyry Jahkola via swift-evolution

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 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 as a “metatype of T”. (Array - Array of Element 
> type)
> Since Subtype in reality is some *existential metatype* and the whole talk 
> about existential types now tend to have the Any prefix, lets follow that 
> trend here too.
> 
> Type - (static/concrete/exact) metatype.
> AnyType - existential metatype.
> It might be even easier to memorise this name than Subtype.
> 
> The example from the proposal rewritten:
> 
> // Types:
> protocol Foo {}
> protocol Boo : Foo {}
> class A : Foo {}
> class B : A, Boo {}
> struct S : Foo {}
> 
> // Metatypes:
> let a1: Type = A.self   //=> Okay
> let p1: Type = Foo.self   //=> Okay
> let p2: Type = C.self //=> Error -- `C` is not the same as `Foo`
> 
> let any_1: AnyType = A.self   //=> Okay
> let any_2: AnyType = Foo.self //=> Okay
> 
> let a_1: AnyType = A.self   //=> Okay
> let p_1: AnyType = A.self //=> Okay
> let p_2: AnyType = Foo.self   //=> Error -- `Type` is not a subtype 
> of `AnyType`
> 
> // Generic functions:
> func dynamic(type: AnyType, `is` _: Type) -> Bool {
>   return type is AnyType
> }
> 
> func dynamic(type: AnyType, `as` _: Type) -> AnyType? {
>   return type as? AnyType
> }
> 
> let s1: Type = S.self
> 
> dynamic(type: s1, is: Foo.self)//=> true
> dynamic(type: s1, as: Foo.self)//=> an `Optional`
> The type(of:) function could now stay, because now we’d only need to change 
> the return type.
> 
> func type(of instance: T) -> AnyType
> Isn’t this a good compromise?
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 2. Oktober 2016 um 09:01:45, Pyry Jahkola via swift-evolution 
> (swift-evolution@swift.org) schrieb:
> 
>> OTOH, we don't have ArrayOf or DictionaryOfKeyAndValue, 
>> while we still pronounce them that way. I don't think prepositions belong in 
>> the name of types but in exceptional cases, and this doesn't sound 
>> exceptional enough to me.
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2016-10-02 Thread Adrian Zubarev via swift-evolution

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 as a “metatype of T”. (Array - Array of Element type)
Since Subtype in reality is some *existential metatype* and the whole talk 
about existential types now tend to have the Any prefix, lets follow that trend 
here too.

Type - (static/concrete/exact) metatype.
AnyType - existential metatype.
It might be even easier to memorise this name than Subtype.

The example from the proposal rewritten:

// Types:
protocol Foo {}
protocol Boo : Foo {}
class A : Foo {}
class B : A, Boo {}
struct S : Foo {}

// Metatypes:
let a1: Type = A.self   //=> Okay
let p1: Type = Foo.self   //=> Okay
let p2: Type = C.self //=> Error -- `C` is not the same as `Foo`

let any_1: AnyType = A.self   //=> Okay
let any_2: AnyType = Foo.self //=> Okay

let a_1: AnyType = A.self   //=> Okay
let p_1: AnyType = A.self //=> Okay
let p_2: AnyType = Foo.self   //=> Error -- `Type` is not a subtype 
of `AnyType`

// Generic functions:
func dynamic(type: AnyType, `is` _: Type) -> Bool {
  return type is AnyType
}

func dynamic(type: AnyType, `as` _: Type) -> AnyType? {
  return type as? AnyType
}

let s1: Type = S.self

dynamic(type: s1, is: Foo.self)//=> true
dynamic(type: s1, as: Foo.self)//=> an `Optional`
The type(of:) function could now stay, because now we’d only need to change the 
return type.

func type(of instance: T) -> AnyType
Isn’t this a good compromise?



-- 
Adrian Zubarev
Sent with Airmail

Am 2. Oktober 2016 um 09:01:45, Pyry Jahkola via swift-evolution 
(swift-evolution@swift.org) schrieb:

OTOH, we don't have ArrayOf or DictionaryOfKeyAndValue, 
while we still pronounce them that way. I don't think prepositions belong in 
the name of types but in exceptional cases, and this doesn't sound exceptional 
enough to me.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2016-10-02 Thread Pyry Jahkola via swift-evolution

> 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 your reply on that, I am still a bit at loss. Maybe we 
> need other words altogether?

OTOH, we don't have ArrayOf or DictionaryOfKeyAndValue, 
while we still pronounce them that way. I don't think prepositions belong in 
the name of types but in exceptional cases, and this doesn't sound exceptional 
enough to me.

— Pyry

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2016-10-01 Thread Goffredo Marocchi via swift-evolution

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 loss. Maybe we need 
other words altogether?

Sent from my iPhone

On 2 Oct 2016, at 05:04, Brent Royal-Gordon via swift-evolution 
 wrote:

>> 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 
>> type of T then let’s just call it StaticType. If the thing most people 
>> want to work with is the dynamic type Subtype then let’s just call it 
>> that: DynamicType.
>> 
>> Now this becomes really clear:
>> 
>> class A { }
>> class B: A { }
>> 
>> //clearly only ever represents A as a type
>> let metatype_1 = statictype(of: A())
>> 
>> //clearly might dynamically be A, B, or any subclass
>> let metatype_2 = dynamictype(of: A())
>> 
>> 
>> It also becomes trivially easy to explain because the name follows the 
>> explanation. Why can I only use required initializers on DynamicType? 
>> Because we don’t know if the initializer is available; the dynamic type may 
>> differ at runtime. StaticType knows exactly what is available on A 
>> because it is statically known at compile time.
> 
> But that *isn't* clear about the relationship between DynamicType and 
> StaticType—specifically, that there are no concrete DynamicTypes, and all 
> DynamicType variables will contain StaticType instances.
> 
> In some drafts, I suggested pairs like `Type` and `SpecificType`:
> 
>func type(of: T) -> Type
>func size(of: SpecificType) -> Int
> 
> (Incidentally, a third benefit of the redesign is that parameters can now be 
> clear about whether they're actually sensitive to the specific dynamic type 
> you pass or they're just being used to pin a generic parameter to a static 
> type. For instance, when you call 
> `UnsafeMutableRawPointer.initializeMemory(as:at:count:to:)`, it doesn't care 
> what dynamic type you pass, but when you call 
> `URLProtocol.registerClass(_:)`, it does. This would be represented—using the 
> proposal's names—by `initializeMemory` taking a `Type` and `URLProtocol` 
> taking a `Subtype` or `Subtype`.)
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2016-10-01 Thread Brent Royal-Gordon via swift-evolution

> 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 type of T 
> then let’s just call it StaticType. If the thing most people want to work 
> with is the dynamic type Subtype then let’s just call it that: 
> DynamicType.
> 
> Now this becomes really clear:
> 
> class A { }
> class B: A { }
> 
> //clearly only ever represents A as a type
> let metatype_1 = statictype(of: A())
> 
> //clearly might dynamically be A, B, or any subclass
> let metatype_2 = dynamictype(of: A())
> 
> 
> It also becomes trivially easy to explain because the name follows the 
> explanation. Why can I only use required initializers on DynamicType? 
> Because we don’t know if the initializer is available; the dynamic type may 
> differ at runtime. StaticType knows exactly what is available on A because 
> it is statically known at compile time.

But that *isn't* clear about the relationship between DynamicType and 
StaticType—specifically, that there are no concrete DynamicTypes, and all 
DynamicType variables will contain StaticType instances.

In some drafts, I suggested pairs like `Type` and `SpecificType`:

func type(of: T) -> Type
func size(of: SpecificType) -> Int

(Incidentally, a third benefit of the redesign is that parameters can now be 
clear about whether they're actually sensitive to the specific dynamic type you 
pass or they're just being used to pin a generic parameter to a static type. 
For instance, when you call 
`UnsafeMutableRawPointer.initializeMemory(as:at:count:to:)`, it doesn't care 
what dynamic type you pass, but when you call `URLProtocol.registerClass(_:)`, 
it does. This would be represented—using the proposal's names—by 
`initializeMemory` taking a `Type` and `URLProtocol` taking a 
`Subtype` or `Subtype`.)

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2016-09-30 Thread Russ Bishop via swift-evolution


> 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 specific Type?
> 
> Let's turn this around. Suppose you write:
> 
>   let obj: NSObject = …
>   let ty = type(of: obj)
> 
> What is `ty`? Well, it's a `Type`, and there's only one of those: 
> `NSObject.self`. So there's only one possible instance that could be assigned 
> to that variable.
> 
> This is true in general: If `type(of:)` returns `Type`, then it can only 
> have one possible return value. In other words, the return value of 
> `type(of:)` would always be the *static* type of the variable, not its 
> dynamic type. There may be some narrow cases where that'd be useful, but 99% 
> of the time, you want `subtype(of:)` because you're trying to discover which 
> of many dynamic subtypes of the static type you're actually dealing with. So 
> most uses of `type(of:)` would probably be mistaken attempts to perform 
> `subtype(of:)` instead.
> 
>> What is the rationale for losing the meta type relationships by having 
>> Type not be a subtype of Type?
> 
> The relationships aren't lost; they're just expressed through `Subtype`, not 
> `Type`.
> 
> Again, turn this around. `Subtype` is the normal thing that you'll want to 
> use most of the time. `Type` is the weird thing whose existence is hard to 
> explain. (One version of this proposal used `Type` for `Subtype` and 
> `ExactType` for `Type` in order to imply that subtype is usually what you 
> want, but some of the contributors weren't happy with that.)
> 
> So, `Type` is the weird thing. Why does it exist? Two reasons:
> 
> 1. `Subtype` only includes *inheritable* type members of `T`. `Type` 
> also includes *non-inheritable* members, particularly non-required 
> initializers.
> 
> 2. It allows precise type matches: `subty is Subtype` would match 
> for any subtype of `NSObject`, whereas `subty is Type` would only 
> match for `NSObject` itself.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 

I understand what you’re getting at. 

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 type of T then 
let’s just call it StaticType. If the thing most people want to work with is 
the dynamic type Subtype then let’s just call it that: DynamicType.

Now this becomes really clear:

class A { }
class B: A { }

//clearly only ever represents A as a type
let metatype_1 = statictype(of: A())

//clearly might dynamically be A, B, or any subclass
let metatype_2 = dynamictype(of: A())


It also becomes trivially easy to explain because the name follows the 
explanation. Why can I only use required initializers on DynamicType? 
Because we don’t know if the initializer is available; the dynamic type may 
differ at runtime. StaticType knows exactly what is available on A because 
it is statically known at compile time.


Russ

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2016-09-30 Thread Xiaodi Wu via swift-evolution

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 non-inheritable
> members of T? Where do these come into play? How is the current T.Type
> deficient in this respect?
>
> Consider a snippet of code like this:
>
> class A { init(a: Int) { } }
> class B: A { init(b: Int) { super.init(a: b) } }
>
> You can call `A.init(a:)` directly:
>
> A(a: 0)
> A.self.init(a: 0)
>
> However, if you try to assign `A`'s type instance to a variable and do it
> through there, you can't:
>
> let aType: A.Type = A.self
> aType.init(a: 0)// Error: constructing an object
> of class type 'A' with a metatype value must use a 'required' initializer
>
> This is a reflection of the fact that an `A.Type` could be `A.self` or
> `B.self` (or any other subclass of `A`), and `B.self` may not have an
> `init(a:)`.
>
> `Type` does not have this problem because it *is* guaranteed to be an
> `A`. It can express initializers and potentially anything else we might add
> that doesn't get inherited.
>
> Of course, that isn't hugely useful right now because `Type` only has
> one instance, and you can just refer to that instance directly. But I don't
> like that this distinction is unutterable; `Type` corrects that.
>
> And I think we may have features in the future where this is useful. For
> instance, if reflection ever gains the ability to access
> non-stored-property members, the distinction between `Subtype` and
> `Type` may become important. And if we ever get the ability to conform
> metatypes to protocols, I think non-inheritable conformances may be a good
> thing.
>
> > Regarding (2), it is already possible to do precise type matches using
> `==` instead of `is` (see corelibs-foundation for extensive uses). What
> does the proposal offer that goes beyond what we currently have?
>
> `as?` compatibility, I suppose? Honestly, that's just something I noticed
> when I was writing it up. It might not be important.
>

This is a very clear answer. So for my understanding, what you're saying
is: without other language features not yet proposed, `Type` does not in
itself enable a particularly notable use case that's not currently possible
today. It is being included in this proposal because the original design of
Swift lumped two things together for simplicity, but you disagree with that
design decision and want the distinction to be utterable. Is that more or
less the gist of it?

--
> Brent Royal-Gordon
> Architechies
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2016-09-30 Thread Brent Royal-Gordon via swift-evolution

> 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 this 
> respect?

Consider a snippet of code like this:

class A { init(a: Int) { } }
class B: A { init(b: Int) { super.init(a: b) } }

You can call `A.init(a:)` directly:

A(a: 0)
A.self.init(a: 0)

However, if you try to assign `A`'s type instance to a variable and do it 
through there, you can't:

let aType: A.Type = A.self
aType.init(a: 0)// Error: constructing an object of 
class type 'A' with a metatype value must use a 'required' initializer

This is a reflection of the fact that an `A.Type` could be `A.self` or `B.self` 
(or any other subclass of `A`), and `B.self` may not have an `init(a:)`.

`Type` does not have this problem because it *is* guaranteed to be an `A`. 
It can express initializers and potentially anything else we might add that 
doesn't get inherited.

Of course, that isn't hugely useful right now because `Type` only has one 
instance, and you can just refer to that instance directly. But I don't like 
that this distinction is unutterable; `Type` corrects that.

And I think we may have features in the future where this is useful. For 
instance, if reflection ever gains the ability to access non-stored-property 
members, the distinction between `Subtype` and `Type` may become 
important. And if we ever get the ability to conform metatypes to protocols, I 
think non-inheritable conformances may be a good thing.

> Regarding (2), it is already possible to do precise type matches using `==` 
> instead of `is` (see corelibs-foundation for extensive uses). What does the 
> proposal offer that goes beyond what we currently have?

`as?` compatibility, I suppose? Honestly, that's just something I noticed when 
I was writing it up. It might not be important.

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2016-09-30 Thread Adrian Zubarev via swift-evolution

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 of 
T (U : T) are subtypes of this existential metatype.
Forget about protocols for a moment:

struct S { }  

let metatype_1: Any.Type = S.self // <~~ (concrete) metatype
//  ^ existential metatype

let metatype_s: S.Type = S.self // <~~ (concrete) metatype
//  ^ existential metatype

/*
   The relationship looks here like this

   (concrete metatype) `T.Type : T.Type` (existential metatype)  

   OR for the given example: `S.Type : S.Type : Any.Type` (last one is again an 
existential metatype)
   This looks confusing right?
*/

class B { }
class D : B { }

let metatype_b: B.Type = B.self // <~~ (concrete) metatype
//  ^ existential metatype

metatype_b is D.Type // false

let metatype_d: D.Type = D.self // <~~ (concrete) metatype
//  ^ existential metatype

let metatype_2: B.Type = metatype_d   // Totally fine
let metatype_3: Any.Type = metatype_2 // Okay

metatype_3 is D.Type // true

/*
   Relationship:

   (existential metatype) `B.Type : Any.Type` (existential metatype)
   (concrete metatype) `B.Type : B.Type` (existential metatype)

   (existential metatype) `D.Type : B.Type` (existential metatype)
   (concrete metatype) `D.Type : D.Type` (existential metatype)
*/
It should be clear by now that there is this odd T.Type : T.Type relationship. 
We want to correct this behaviour + solve the problem that raises with 
protocols with one simple and single design.

Let’s see what happens with protocols:

protocol P { }  

let metatype_p: P.Type = P.self // Error, because the concrete metatype is not 
a subtype of the existential metatype of P

// Furthermore `P.self` is `P.Protocol`

let metatype_3: Any.Type = P.self // fine <~~ (concrete) metatype
//  ^ existential metatype

/*
   Relationship:
   (concrete metatype) `P.Protocol : Any.Type` (existential metatype)
   (existential metatype) `P.Type : Any.Type` (existential metatype)

   At this time `P.Type : Any.Type` is an existential metatype that exists but 
it does not have any subtypes!
*/

struct I : P { }

let metatype_i: I.Type = I.self // <~~ (concrete) metatype
//  ^ existential metatype

let metatype_4: P.Type = metatype_i // fine
//  ^ existential metatype

metatype_4 is I.Type // true

/*
   Relationship:
   (existential metatype) `P.Type : Any.Type` (existential metatype)
   (existential metatype) `I.Type : P.Type` (existential metatype)
   (concrete metatype) `I.Type : I.Type` (existential metatype)
*/
There is a huge overlap in the current design. I hope this cleared your 
question here.

Side note: The following function isn’t possible to implement with the current 
T.Type design because in generic context a protocol will end up T.Protocol.

func dynamic(subtype: Subtype, `is` _: Type) -> Bool {
  return type is Subtype
}
The proposed design however solves these problems and the relationship becomes 
clearer:

(existential metatype) `Subtype : Subtype` (existential metatype)
(concrete metatype) `Type : Subtype` (existential metatype)

(existential metatype) `Subtype : Subtype` (existential metatype)
(concrete metatype) `Type : Subtype` (existential metatype)

(existential metatype) `Subtype : Subtype` (existential metatype)
(concrete metatype) `Type : Subtype` (existential metatype)

(existential metatype) `Subtype : Subtype` (existential metatype)
(existential metatype) `Subtype : Subtype` (existential metatype)
(concrete metatype) `Type : Subtype` (existential metatype)
The only way to work with Subtype is by using subtype(of:) function of by 
manually shadowing a concrete metatype Type.

The only way to instantiate a concrete metatype is done with T.self.



-- 
Adrian Zubarev
Sent with Airmail

Am 30. September 2016 um 21:48:39, Xiaodi Wu (xiaodi...@gmail.com) schrieb:

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:

https://gist.github.com/xwu/0cc2c8d358f1fdf066ba739bcd151167


On Fri, Sep 30, 2016 at 2:09 PM, Adrian Zubarev via swift-evolution 
 wrote:
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 is also the base type for all subtypes of T.

Protocols has one exception here.

1.1. The concrete type for protocols is not T.Type but

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

2016-09-30 Thread Anton Zhilin via swift-evolution

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 for some
> elaboration. I've tried to clarify my question in a gist:
>
> https://gist.github.com/xwu/0cc2c8d358f1fdf066ba739bcd151167
>
Regardless of syntax, there are Metatype and ExistentialMetatype
“under the hood”. I’ll take the liberty to use these names for this post.

Purpose and difference between the two kinds of metatypes is easy to
understand. If it helps, size of Metatype is typically 0 while size of
ExistentialMetatype is typically 8.

NOTE: Metatype can’t be a subtype of ExistentialMetatype for
protocols P, because protocols do not implement their own static
requirements.

Apparently, creators of Swift also thought that two kinds of metatypes are
too difficult for an average developer. So an attempt was made to unify
both under a single name, T.Type. For “final” types like structs, T.Type
maps onto Metatype. For classes and protocols, T.Type maps onto
ExistentialMetatype.

This abstraction turned out to be leaky. I’ll give 3 leaks.

   1. Because of Note, we could not have ID of a protocol itself inside of
   any kind of metatype. This feature was needed in real code. The solution
   was to add T.Protocol syntax that could only be used for protocols to
   create a Metatype. But this solution created a plethora of other
   inconsistencies and abstraction leaks (which were explored by Adrian).
   Arguably the most important is (2).
   2. In generic functions accepting T.Type, passing T.self creates an
   instance of T.Protocol, which is still described in code as T.Type.
   *boom!*
   3. Accepting static metatypes in functions is often what people want.
   Consider the following basic example:

func create(type: T.Type)

Most probably, create does not read contents of type to deal with
appropriate subtype. It does not support existentiality, type is here for
function specialization. But in case T is subtypable, we still pass around
those 8 bytes that are not used by the create, confusing both compiler and
some developers. In 90% cases, when we see such a function, it throws off
value of metatype instance.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2016-09-30 Thread Xiaodi Wu via swift-evolution

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:

https://gist.github.com/xwu/0cc2c8d358f1fdf066ba739bcd151167


On Fri, Sep 30, 2016 at 2:09 PM, Adrian Zubarev via swift-evolution <
swift-evolution@swift.org> wrote:

> 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.
>
>1.
>
>It’s a concrete type; we call it Type or other suggested names
>looked like ExactType, StaticType etc.
>2.
>
>T.Type is also the *base type* for all subtypes of T.
>
> Protocols has one exception here.
>
> 1.1. The concrete type for protocols is not T.Type but T.Protocol.
>
> 2.1. T.Protocol has only one supertype, which is the existential (#2)
> Any.Type type.
>
> Our proposal slices this behaviour into two different types, where you
> only can create a *concrete type* Type with T.self or shadow a
> concrete type behind Subtype with subtype(of:) function.
>
> To be precise the correct names should be:
>
>- Metatype for the concrete type (#1).
>- ExistentialMetatype for the existential type (#2).
>
> But we felt that we should adopt the existing name from T.Type and use
> the short form for the *concrete type* Type.
> --
>
> Brent already showed in multiple examples but the question seems to come
> up over and over about the correct name of the current type(of:) function.
>
> Imagine this scenario:
>
> protocol P {}
> struct A : P {}
>
> let proto: P = A()
> let any: Any = proto
>
> // the old behaviour looked like this
>
> // *concrete* `A.Type` is hidden behind the existential `Any.Type`
> let anyMetatype: Any.Type = any.dynamicType
>
> anyMetatype is P.Type //=> true `P.Type` is the existential type here
> anyMetatype is A.Type //=> true
> let aMetatype = anyMetatype as! A.Type // Okay
>
> // today `type(of:)` does the same trick
>
> // After this proposal:
> // subtype(of instance: T) -> Subtype
>
> // The function will extract `Type` for `any` but shadow it behind 
> `Subtype`
> let anyMetatype: `Subtype` = subtype(of: any)
>
> // The correct relationship look like this:
> // Subtype : Subtype
> // Subtype : Subtype
> // Type : Subtype
>
> anyMetatype is Subtype //=> true
> anyMetatype is Subtype //=> true
> anyMetatype is Type//=> true
> anyMetatype is Type//=> false
> anyMetatype is Type  //=> false
> let aMetatype_1 = anyMetatype as! Subtype // Okay
> let aMetatype_2 = anyMetatype as! Type// Okay
>
> subtype(of:) function extracts the *concrete type* from the given
> instance but shadows it behind the *existential type* equal to the type of
> the given instance.
>
> subtype(of: T) returns a existential metatype instance Subtype where
> in reality it’s a concrete metatype Type with the relationship like U
> : T.
>
> This is exact the same behaviour as the old .dynamicType had.
>
> I hope that cleared some raising questions.
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 30. September 2016 um 09:00:53, Goffredo Marocchi via swift-evolution (
> swift-evolution@swift.org) schrieb:
>
> Calling it SuperTypeOf and SubTypeOf would make it less confusing as
> that is how I read it in my mind in your last example.
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2016-09-30 Thread Adrian Zubarev via swift-evolution

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 is also the base type for all subtypes of T.

Protocols has one exception here.

1.1. The concrete type for protocols is not T.Type but T.Protocol.

2.1. T.Protocol has only one supertype, which is the existential (#2) Any.Type 
type.

Our proposal slices this behaviour into two different types, where you only can 
create a *concrete type* Type with T.self or shadow a concrete type behind 
Subtype with subtype(of:) function.

To be precise the correct names should be:

Metatype for the concrete type (#1).
ExistentialMetatype for the existential type (#2).
But we felt that we should adopt the existing name from T.Type and use the 
short form for the *concrete type* Type.

Brent already showed in multiple examples but the question seems to come up 
over and over about the correct name of the current type(of:) function.

Imagine this scenario:

protocol P {}
struct A : P {}

let proto: P = A()
let any: Any = proto

// the old behaviour looked like this

// *concrete* `A.Type` is hidden behind the existential `Any.Type`
let anyMetatype: Any.Type = any.dynamicType  

anyMetatype is P.Type //=> true `P.Type` is the existential type here
anyMetatype is A.Type //=> true
let aMetatype = anyMetatype as! A.Type // Okay

// today `type(of:)` does the same trick

// After this proposal:
// subtype(of instance: T) -> Subtype

// The function will extract `Type` for `any` but shadow it behind 
`Subtype`
let anyMetatype: `Subtype` = subtype(of: any)

// The correct relationship look like this:
// Subtype : Subtype
// Subtype : Subtype
// Type : Subtype

anyMetatype is Subtype //=> true
anyMetatype is Subtype //=> true
anyMetatype is Type//=> true
anyMetatype is Type//=> false
anyMetatype is Type  //=> false
let aMetatype_1 = anyMetatype as! Subtype // Okay
let aMetatype_2 = anyMetatype as! Type// Okay
subtype(of:) function extracts the *concrete type* from the given instance but 
shadows it behind the *existential type* equal to the type of the given 
instance.

subtype(of: T) returns a existential metatype instance Subtype where in 
reality it’s a concrete metatype Type with the relationship like U : T.

This is exact the same behaviour as the old .dynamicType had.

I hope that cleared some raising questions.



-- 
Adrian Zubarev
Sent with Airmail

Am 30. September 2016 um 09:00:53, Goffredo Marocchi via swift-evolution 
(swift-evolution@swift.org) schrieb:

Calling it SuperTypeOf and SubTypeOf would make it less confusing as that 
is how I read it in my mind in your last example.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2016-09-30 Thread Adrian Zubarev via swift-evolution

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() // <— Yeay
This proposal also aims to fix the problem with generics where any protocol 
metatype was converted to P.Protocol.


-- 
Adrian Zubarev
Sent with Airmail

Am 30. September 2016 um 06:22:34, Xiaodi Wu via swift-evolution 
(swift-evolution@swift.org) schrieb:

What does the proposal offer that goes beyond what we currently have?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2016-09-30 Thread Goffredo Marocchi via swift-evolution

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: Supertype = NSView.self


Calling it SuperTypeOf and SubTypeOf would make it less confusing as that 
is how I read it in my mind in your last example.

Sent from my iPhone

On 30 Sep 2016, at 04:57, Brent Royal-Gordon via swift-evolution 
 wrote:

>> 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 when you explain that this 
>> is often *not* what you would want)?
> 
> I'm short-handing the names to talk about the return values. In other words, 
> I assume that, if we have both `type(of:)` and `subtype(of:)`, their 
> signatures would be:
> 
>func type(of: T) -> Type
>func subtype(of: T) -> Subtype
> 
> And I'm saying that, given these names, `type(of:)` is confusing and 
> near-useless, whereas `subtype(of:)` is what you almost always want.
> 
> We *could*, of course, have a function called `type(of:)` which returned 
> `Subtype` and had the semantics I'm referring to as `subtype(of:)`. A name 
> is just a name.
> 
>> I'm also somewhat puzzled about the proposed design. This proposal explains 
>> that Subtype should be a supertype of Type and its subtypes. Why is a 
>> supertype named Subtype?
> 
> Because a type's name should describe the *instances*; that's why you don't 
> put "Class" at the end of all of your class names. (It's also why we're 
> proposing `Type` instead of `Metatype`.)
> 
> Every instance of `Subtype` is the type instance for a subtype of `T`. For 
> instance, in this hierarchy:
> 
>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: Supertype = NSView.self
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2016-09-29 Thread Xiaodi Wu via swift-evolution

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 precise type matches using `==`
instead of `is` (see corelibs-foundation for extensive uses). What does the
proposal offer that goes beyond what we currently have?


On Thu, Sep 29, 2016 at 22:57 Brent Royal-Gordon 
wrote:

> > On Sep 29, 2016, at 8:14 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> 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 when you explain that
> this is often *not* what you would want)?
>
> I'm short-handing the names to talk about the return values. In other
> words, I assume that, if we have both `type(of:)` and `subtype(of:)`, their
> signatures would be:
>
> func type(of: T) -> Type
> func subtype(of: T) -> Subtype
>
> And I'm saying that, given these names, `type(of:)` is confusing and
> near-useless, whereas `subtype(of:)` is what you almost always want.
>
> We *could*, of course, have a function called `type(of:)` which returned
> `Subtype` and had the semantics I'm referring to as `subtype(of:)`. A
> name is just a name.
>
> > I'm also somewhat puzzled about the proposed design. This proposal
> explains that Subtype should be a supertype of Type and its subtypes.
> Why is a supertype named Subtype?
>
> Because a type's name should describe the *instances*; that's why you
> don't put "Class" at the end of all of your class names. (It's also why
> we're proposing `Type` instead of `Metatype`.)
>
> Every instance of `Subtype` is the type instance for a subtype of `T`.
> For instance, in this hierarchy:
>
> 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: Supertype = NSView.self
>
> --
> Brent Royal-Gordon
> Architechies
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2016-09-29 Thread Brent Royal-Gordon via swift-evolution

> 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 when you explain that this 
> is often *not* what you would want)?

I'm short-handing the names to talk about the return values. In other words, I 
assume that, if we have both `type(of:)` and `subtype(of:)`, their signatures 
would be:

func type(of: T) -> Type
func subtype(of: T) -> Subtype

And I'm saying that, given these names, `type(of:)` is confusing and 
near-useless, whereas `subtype(of:)` is what you almost always want.

We *could*, of course, have a function called `type(of:)` which returned 
`Subtype` and had the semantics I'm referring to as `subtype(of:)`. A name 
is just a name.

> I'm also somewhat puzzled about the proposed design. This proposal explains 
> that Subtype should be a supertype of Type and its subtypes. Why is a 
> supertype named Subtype?

Because a type's name should describe the *instances*; that's why you don't put 
"Class" at the end of all of your class names. (It's also why we're proposing 
`Type` instead of `Metatype`.)

Every instance of `Subtype` is the type instance for a subtype of `T`. For 
instance, in this hierarchy:

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: Supertype = NSView.self

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2016-09-29 Thread Xiaodi Wu via swift-evolution

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 design. This proposal explains
that Subtype should be a supertype of Type and its subtypes. Why is a
supertype named Subtype?
On Thu, Sep 29, 2016 at 9:44 PM Nevin Brackett-Rozinsky via swift-evolution
 wrote:

> 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 PM, Russ Bishop via swift-evolution <
>> swift-evolution@swift.org> 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 = …
>> let ty = type(of: obj)
>>
>> What is `ty`? Well, it's a `Type`, and there's only one of
>> those: `NSObject.self`. So there's only one possible instance that could be
>> assigned to that variable.
>>
>> This is true in general: If `type(of:)` returns `Type`, then it can
>> only have one possible return value. In other words, the return value of
>> `type(of:)` would always be the *static* type of the variable, not its
>> dynamic type. There may be some narrow cases where that'd be useful, but
>> 99% of the time, you want `subtype(of:)` because you're trying to discover
>> which of many dynamic subtypes of the static type you're actually dealing
>> with. So most uses of `type(of:)` would probably be mistaken attempts to
>> perform `subtype(of:)` instead.
>>
>> > What is the rationale for losing the meta type relationships by having
>> Type not be a subtype of Type?
>>
>> The relationships aren't lost; they're just expressed through `Subtype`,
>> not `Type`.
>>
>> Again, turn this around. `Subtype` is the normal thing that you'll want
>> to use most of the time. `Type` is the weird thing whose existence is hard
>> to explain. (One version of this proposal used `Type` for `Subtype` and
>> `ExactType` for `Type` in order to imply that subtype is usually what you
>> want, but some of the contributors weren't happy with that.)
>>
>> So, `Type` is the weird thing. Why does it exist? Two reasons:
>>
>> 1. `Subtype` only includes *inheritable* type members of `T`.
>> `Type` also includes *non-inheritable* members, particularly
>> non-required initializers.
>>
>> 2. It allows precise type matches: `subty is Subtype` would
>> match for any subtype of `NSObject`, whereas `subty is Type`
>> would only match for `NSObject` itself.
>>
>> --
>> Brent Royal-Gordon
>> Architechies
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2016-09-29 Thread Nevin Brackett-Rozinsky via swift-evolution

>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 PM, Russ Bishop via swift-evolution <
> swift-evolution@swift.org> 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 = …
> let ty = type(of: obj)
>
> What is `ty`? Well, it's a `Type`, and there's only one of
> those: `NSObject.self`. So there's only one possible instance that could be
> assigned to that variable.
>
> This is true in general: If `type(of:)` returns `Type`, then it can
> only have one possible return value. In other words, the return value of
> `type(of:)` would always be the *static* type of the variable, not its
> dynamic type. There may be some narrow cases where that'd be useful, but
> 99% of the time, you want `subtype(of:)` because you're trying to discover
> which of many dynamic subtypes of the static type you're actually dealing
> with. So most uses of `type(of:)` would probably be mistaken attempts to
> perform `subtype(of:)` instead.
>
> > What is the rationale for losing the meta type relationships by having
> Type not be a subtype of Type?
>
> The relationships aren't lost; they're just expressed through `Subtype`,
> not `Type`.
>
> Again, turn this around. `Subtype` is the normal thing that you'll want to
> use most of the time. `Type` is the weird thing whose existence is hard to
> explain. (One version of this proposal used `Type` for `Subtype` and
> `ExactType` for `Type` in order to imply that subtype is usually what you
> want, but some of the contributors weren't happy with that.)
>
> So, `Type` is the weird thing. Why does it exist? Two reasons:
>
> 1. `Subtype` only includes *inheritable* type members of `T`. `Type`
> also includes *non-inheritable* members, particularly non-required
> initializers.
>
> 2. It allows precise type matches: `subty is Subtype` would
> match for any subtype of `NSObject`, whereas `subty is Type`
> would only match for `NSObject` itself.
>
> --
> Brent Royal-Gordon
> Architechies
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2016-09-29 Thread Brent Royal-Gordon via swift-evolution

> 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 = …
let ty = type(of: obj)

What is `ty`? Well, it's a `Type`, and there's only one of those: 
`NSObject.self`. So there's only one possible instance that could be assigned 
to that variable.

This is true in general: If `type(of:)` returns `Type`, then it can only 
have one possible return value. In other words, the return value of `type(of:)` 
would always be the *static* type of the variable, not its dynamic type. There 
may be some narrow cases where that'd be useful, but 99% of the time, you want 
`subtype(of:)` because you're trying to discover which of many dynamic subtypes 
of the static type you're actually dealing with. So most uses of `type(of:)` 
would probably be mistaken attempts to perform `subtype(of:)` instead.

> What is the rationale for losing the meta type relationships by having 
> Type not be a subtype of Type?

The relationships aren't lost; they're just expressed through `Subtype`, not 
`Type`.

Again, turn this around. `Subtype` is the normal thing that you'll want to use 
most of the time. `Type` is the weird thing whose existence is hard to explain. 
(One version of this proposal used `Type` for `Subtype` and `ExactType` for 
`Type` in order to imply that subtype is usually what you want, but some of the 
contributors weren't happy with that.)

So, `Type` is the weird thing. Why does it exist? Two reasons:

1. `Subtype` only includes *inheritable* type members of `T`. `Type` also 
includes *non-inheritable* members, particularly non-required initializers.

2. It allows precise type matches: `subty is Subtype` would match for 
any subtype of `NSObject`, whereas `subty is Type` would only match 
for `NSObject` itself.

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2016-09-29 Thread Russ Bishop via swift-evolution


> 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 interesting, because it is actually a 
> magic syntax rather than a function. We propose to align this syntax with 
> Type and Subtype by renaming it to Subtype(of:). We believe this is clearer 
> about both the type and meaning of the operation.
> 
Why would we not have type(of:) and subtype(of:)? Why would I want the 
Subtype instead of the specific Type?

What is the rationale for losing the meta type relationships by having Type 
not be a subtype of Type?


> let anInstance: NSObject = NSString()
> let aClass: Subtype = Subtype(of: anInstance)
> 
> print(aClass) // => NSString
> More details:
> 
> Every static or class member of T which can be called on all subtypes is an 
> instance member of Subtype. That includes:
> 
> Static/class properties and methods
> 
> Required initializers (as methods named init)
> 
> Unbound instance methods
> 
> The Type of a concrete type T has all of the members required by 
> Subtype, plus non-required initializers.
> 
> The Type of a protocol T includes only unbound instance methods of T.
> 
> If T conforms to P, then Subtype is a subtype of Subtype, even if T is 
> a protocol.
> 
> The type of Subtype.self is Type.
> 
> The type of Type.self is Type, which is not a subtype of any type 
> except Subtype. There is an infinite regress of Type<...>s.
> 
> Subtypes are abstract types similar to class-bound protocols; they, too, 
> support identity operations. 
> 
> Types are concrete reference types which have identities just like objects do.
> 
> swift Int.self === Int.self // true Int.self === Any.self // false
> 
> 
> Some examples
> 
I don’t see C defined in the example.


> Impact on existing code
> 
> This is a source-breaking change that can be automated by a migrator. 
> 
> We suggest the following migration process; this can differ from the final 
> migration process implemented by the core team if this proposal will be 
> accepted:
> 
To the extent possible I suggest that Swift 4+ stick to deprecations unless it 
presents a significant effort. I think a lot of people are a bit exhausted with 
huge syntax changes and the impression was that most source-breaking changes 
were being done in Swift 3 so we could do them once.


> Alternatives considered
> 
> Other names for Type and Subtype were considered:
> 
> Type: SpecificType, Metatype or ExactType.
> Subtype: Supertype, Base, BaseType, ExistentialType or TypeProtocol.
> Alternatively the pseudo initializer Subtype(of:) could remain as a global 
> function:
> 
> public func subtype(of instance: T) -> Subtype
> -- 
> Adrian Zubarev
> Sent with Airmail

I think there is some potential for confusion with Subtype, but I don’t want 
to bike shed it too much :)


Overall looks really nice!

Russ


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2016-09-29 Thread Anton Zhilin via swift-evolution

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 all Types whose instances are subtypes
>of T, including T itself:
>-
>
>If T is a struct or enum, then Type is the only subtype of
>Subtype.
>-
>
>If T is a class, then Type and the Types of all subclasses of T are
>subtypes of Subtype.
>-
>
>If T is a protocol, then the Types of all concrete types conforming to
>T are subtypes of Subtype. Type is not itself a subtype of
>Subtype, or of any Subtype other than Subtype.
>
> I’m having trouble reconciling this with rule #2 above, which states that
> “Subtype is the supertype of all Types whose instances are subtypes of T,
> including T itself.” Which one is wrong, or am I confused?
>
#2 applies to types, and #5 applies to protocols. If T is a type, then
Type is always a subtype of Subtype. If T is a protocol, then Type
is never a subtype of Subtype.

One thing I haven’t understood the motivation for exactly is what someone
> would be able to do with a Proto.self. Dynamic conformance checking? For a
> concrete T, having its .self seems useful for doing dynamic casts and such,
> but I don’t understand why for a Proto you need to have both. You did a
> good job of explaining why T.Protocol and T.Type are different, but not why
> both of them need to exist. So you could definitely do more to spell out
> the use-cases here.
>
I honestly can’t imagine a use case for .Protocol currently. Maybe
enumerating protocols that exist in the program, just for the sake of it.


>-
>
>Metatypes of functions are a little bit more special (the subtyping
>relation on functions flips around for parameter types
>
> 
>):
>-
>   - Type<(Any) -> Void> is a subtype of Subtype<(Int) -> Void> etc.
>   - Type<(Void) -> Int> is a subtype of Subtype<(Void) -> Any>
>
>
> Does this potentially expose contravariant type parameters, and is that an
> issue? (I’m trying to imagine a scenario where you could have an A on the
> left hand side of an arrow and have that leak out to other clients, but I
> haven’t had a chance to write much Swift 3 yet, unfortunately.)
>
Could you give a code example, where that would be an issue?

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2016-09-28 Thread Colin Barrett via swift-evolution

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: 
> https://github.com/DevAndArtist/swift-evolution/blob/refactor_metatypes/proposals/0126-refactor-metatypes.md
>  
> 
> Refactor Metatypes
> 
> Proposal: SE–0126 
> 
> Authors: Adrian Zubarev , Anton Zhilin 
> , Brent Royal-Gordon 
> Status: Revision
> Review manager: Chris Lattner 
> Revision: 2
> Previous Revisions: 1 
> 
> Introduction
> 
> This proposal removes .Type and .Protocol in favor of two generic-style 
> syntaxes and aligns global type(of:) function (SE–0096) to match the changes.
> 
> Swift-evolution thread (post Swift 3): 
> 
> [Pitch] Refactor Metatypes 
> 
> Older swift-evolution threads: [1] 
> ,
>  [2] 
> ,
>  [3] 
> 
> Motivation
> 
> Every type T has an instance, accessible through T.self, which represents the 
> type itself. Like all instances in Swift, this “type instance” itself has a 
> type, which is referred to as its “metatype”. The metatype of T is written 
> T.Type. The instance members of the metatype are the same as the static or 
> class members of the type.
> 
> Metatypes have subtype relationships which reflect the types they represent. 
> For instance, given these types:
> 
> protocol Proto {}
> class Base {}
> class Derived: Base, Proto {}
> Derived.Type is a subtype of both Base.Type and Proto.Type (and Any.Type). 
> That means that Derived.self can be used anywhere a Derived.Type, Base.Type, 
> Proto.Type, or Any.Type is called for.
> 
> Unfortunately, this simple picture is complicated by protocols. Proto.self is 
> actually of type Proto.Protocol, not type Proto.Type. This is necessary 
> because the protocol does not, and cannot, conform to itself; it requires 
> conforming types to provide static members, but it doesn’t actually provide 
> those members itself. Proto.Type still exists, but it is the supertype of all 
> types conforming to the protocol.
> 
> Making this worse, a generic type always uses T.Type to refer to the type of 
> T.self. So when Proto is bound to a generic parameter P, P.Type is the same 
> as Proto.Protocol.
> 
> This shifting of types is complicated and confusing; we seek to clean up this 
> area.
> 
> We also believe that, in the long term, the dot syntax will prevent us from 
> implementing certain future enhancements that might be valuable:
> 
> Moving the implementation of metatypes at least partly into the standard 
> library.
> Adding members available on all type instances for features like read-write 
> reflection or memory layout information.
> Conforming metatypes to protocols like Hashable or CustomStringConvertible.
> Offering straightforward syntaxes for dynamic features like looking up types 
> by name.
> Proposed solution
> 
> We abolish .Type and .Protocol in favor of two generic-style syntaxes:
> 
> 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 all Types whose instances are subtypes of T, 
> including T itself:
> 
> If T is a struct or enum, then Type is the only subtype of Subtype.
> 
> If T is a class, then Type and the Types of all subclasses of T are 
> subtypes of Subtype.
> 
> If T is a protocol, then the Types of all concrete types conforming to T are 
> subtypes of Subtype. Type is not itself a subtype of Subtype, or of 
> any Subtype other than Subtype.
> 
I’m having trouble reconciling this with rule #2 above, which states that 
“Subtype is the supertype of all Types whose instances are subtypes of T, 
including T itself.” Which one is wrong, or am I confused?

One thing I haven’t understood the motivation for exactly is what someone would 
be able to do with a Proto.self. Dynamic conformance checking? For a concrete 
T, having its .self seems useful for doing dynamic casts and such, but I don’t 
understand why for a Proto you need to have both. You did a good job of 
explaining why T.Protocol and T.Type are different, but not why both of them 
need to exist. So you could definitely do more to spell out the use-cases here.
> Structural types follow the subtype/supertype relationships of their 
> constituent types. For

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

2016-09-28 Thread Nevin Brackett-Rozinsky via swift-evolution

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 not
understand from them what was being proposed and why. After reading this
one, I feel that I finally comprehend the situation, both in terms of how
metatypes behave today and how the authors would like them to work.

This is still an area where I do not have much expertise, so I look forward
to hearing what better-versed people think of the overall approach as well
as the specific details.

Nevin



On Wed, Sep 28, 2016 at 6:18 AM, Adrian Zubarev via swift-evolution <
swift-evolution@swift.org> wrote:

> Formatted version: https://github.com/DevAndArtist/swift-evolution/
> blob/refactor_metatypes/proposals/0126-refactor-metatypes.md
> --
> Refactor Metatypes
>
>- Proposal: SE–0126
>
>- Authors: Adrian Zubarev , Anton
>Zhilin , Brent Royal-Gordon
>
>- Status: *Revision*
>- Review manager: Chris Lattner 
>- Revision: 2
>- Previous Revisions: 1
>
> 
>
> Introduction
>
> This proposal removes .Type and .Protocol in favor of two generic-style
> syntaxes and aligns global type(of:) function (SE–0096) to match the
> changes.
>
> Swift-evolution thread (post Swift 3):
>
>- [Pitch] Refactor Metatypes
>
> Older swift-evolution threads: [1]
> ,
> [2]
> ,
> [3]
> 
> Motivation
>
> Every type T has an instance, accessible through T.self, which represents
> the type itself. Like all instances in Swift, this “type instance” itself
> has a type, which is referred to as its “metatype”. The metatype of T is
> written T.Type. The instance members of the metatype are the same as the
> static or class members of the type.
>
> Metatypes have subtype relationships which reflect the types they
> represent. For instance, given these types:
>
> protocol Proto {}
> class Base {}
> class Derived: Base, Proto {}
>
> Derived.Type is a subtype of both Base.Type and Proto.Type (and Any.Type).
> That means that Derived.self can be used anywhere a Derived.Type,
> Base.Type, Proto.Type, or Any.Type is called for.
>
> Unfortunately, this simple picture is complicated by protocols. Proto.self
> is actually of type Proto.Protocol, not type Proto.Type. This is
> necessary because the protocol does not, and cannot, conform to itself; it
> requires conforming types to provide static members, but it doesn’t
> actually provide those members itself. Proto.Type still exists, but it is
> the supertype of all types conforming to the protocol.
>
> Making this worse, a generic type always uses T.Type to refer to the type
> of T.self. So when Proto is bound to a generic parameter P, P.Type is the
> same as Proto.Protocol.
>
> This shifting of types is complicated and confusing; we seek to clean up
> this area.
>
> We also believe that, in the long term, the dot syntax will prevent us
> from implementing certain future enhancements that might be valuable:
>
>- Moving the implementation of metatypes at least partly into the
>standard library.
>- Adding members available on all type instances for features like
>read-write reflection or memory layout information.
>- Conforming metatypes to protocols like Hashable or
>CustomStringConvertible.
>- Offering straightforward syntaxes for dynamic features like looking
>up types by name.
>
> Proposed solution
>
> We abolish .Type and .Protocol in favor of two generic-style syntaxes:
>
>-
>
>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 all Types whose instances are subtypes
>of T, including T itself:
>-
>
>If T is a struct or enum, then Type is the only subtype of
>Subtype.
>-
>
>If T is a class, then Type and the Types of all subclasses of T are
>subtypes of Subtype.
>-
>
>If T is a protocol, then the Types of all concrete types conforming to
>T are subtypes of Subtype. Type is not itself a subtype of
>Subtype, or of any Subtype other than Subtype.
>-
>
>Structural types follow the subtype/supertype relationships of their
>

40 matches

Mail list logo