Changing postfix "self" to something clearer like "type"

Evolution Discussion
1

One area of swift that is really not clear to me is when you want to use the type of a class, struct, enum, etc as a value.

Metatyping is explained here: Types — The Swift Programming Language (Swift 5.7)

Example:
let metatype: SomeClass.Type = SomeClass.self

Is there a reason why this isn't SomeClass.type? Everywhere in the document this is explained as returning the type yet it's using a postfix self to access the type.

I propose changing the postfix self to something more obvious like "type"

Going back to the example:
let metatype: SomeClass.Type = SomeClass.type

Several reasons why I think this is better:
1. Postfix self is not obvious as an option as you never see a postfix self anywhere else
2. "self" does not clearly explain that the type is being returned
3. ObjC programmers are familiar with accessing the class type by sending the "class" method to the class type. In this case it needs to work on structs and enums, so a "type" method would make more sense.
4. Instances have a dynamicType method. For consistency, classes, structs, etc., should have a type method

Any other suggestions would be welcome.

Brandon

···

Sent from my iPad

2

+1. Side effects can be eliminated through code migration if a suitable
property name is chosen. Perhaps `staticType` to continue in the vein of
`dynamicType`?

Main detractor is that creating more keywords isn't necessarily a good
thing.

···

On Tue, Dec 15, 2015 at 11:19 AM Brandon Knope via swift-evolution < swift-evolution@swift.org> wrote:

One area of swift that is really not clear to me is when you want to use
the type of a class, struct, enum, etc as a value.

Metatyping is explained here:
The Swift Programming Language: Redirect

Example:

   1. let metatype: SomeClass.Type = SomeClass.self

Is there a reason why this isn't SomeClass.type? Everywhere in the
document this is explained as returning the type yet it's using a postfix
self to access the type.

I propose changing the postfix self to something more obvious like "type"

Going back to the example:

   1. let metatype: SomeClass.Type = SomeClass.type

Several reasons why I think this is better:
1. Postfix self is not obvious as an option as you never see a postfix
self anywhere else
2. "self" does not clearly explain that the type is being returned
3. ObjC programmers are familiar with accessing the class type by sending
the "class" method to the class type. In this case it needs to work on
structs and enums, so a "type" method would make more sense.
4. Instances have a dynamicType method. For consistency, classes, structs,
etc., should have a type method

Any other suggestions would be welcome.

Brandon

Sent from my iPad
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

3

".self" was chosen for a few reasons:

- The obvious choice was ".class", given precedent in Objective-C and Java, but not all types are classes.
- 'type' is a very common property name, so we have tried very hard to avoid taking it as a general keyword.
- 'type' also always implies going up a level. "obj.dynamicType" gives you back the type of 'obj', so wouldn't "SomeClass.type" give you back the metaclass <http://sealiesoftware.com/blog/archive/2009/04/14/objc_explain_Classes_and_metaclasses.html&gt;? (Alternately, "SomeType.staticType' not being the same as 'SomeType.dynamicType" seems weird.)
- 'self' is already a keyword.
- ".self" actually works in Objective-C as well.
- ".self" currently also applies to instances, doing exactly what you think it does. This is nearly useless. In theory you could use it to unwrap one level of optionality ("doubleOpt?.self") but that doesn't actually work today.

I read "SomeType.self" as "SomeType itself, rather than an instance of it (or associated type)".

(And before someone brings it up, we chose not to just allow "SomeType" on its own because "let x = SomeType" is a likely typo for "let x: SomeType".)

I think coming up with a clearer name is possible here, but there's plenty to consider. Still, certainly a reasonable thing to bring up.

Best,
Jordan

···

On Dec 15, 2015, at 8:42 , Brandon Knope via swift-evolution <swift-evolution@swift.org> wrote:

Doh! staticType is the obvious choice!

I agree that adding more keywords can be bad, but in this case I think the clarity outweighs any downside:

SomeType.staticType
SomeType.self

To me (and I'm sure many others) one is vastly more obvious and easier to understand.

I still don't really understand what SomeType.self is trying to convey upon first glance

Brandon

Sent from my iPad

On Dec 15, 2015, at 11:34 AM, Dennis Lysenko <dennis.s.lysenko@gmail.com <mailto:dennis.s.lysenko@gmail.com>> wrote:

+1. Side effects can be eliminated through code migration if a suitable property name is chosen. Perhaps `staticType` to continue in the vein of `dynamicType`?

Main detractor is that creating more keywords isn't necessarily a good thing.

On Tue, Dec 15, 2015 at 11:19 AM Brandon Knope via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
One area of swift that is really not clear to me is when you want to use the type of a class, struct, enum, etc as a value.

Metatyping is explained here: The Swift Programming Language: Redirect

Example:
let metatype: SomeClass.Type = SomeClass.self

Is there a reason why this isn't SomeClass.type? Everywhere in the document this is explained as returning the type yet it's using a postfix self to access the type.

I propose changing the postfix self to something more obvious like "type"

Going back to the example:
let metatype: SomeClass.Type = SomeClass.type

Several reasons why I think this is better:
1. Postfix self is not obvious as an option as you never see a postfix self anywhere else
2. "self" does not clearly explain that the type is being returned
3. ObjC programmers are familiar with accessing the class type by sending the "class" method to the class type. In this case it needs to work on structs and enums, so a "type" method would make more sense.
4. Instances have a dynamicType method. For consistency, classes, structs, etc., should have a type method

Any other suggestions would be welcome.

Brandon

Sent from my iPad

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

4

Doh! staticType is the obvious choice!

I agree that adding more keywords can be bad, but in this case I think the clarity outweighs any downside:

SomeType.staticType
SomeType.self

To me (and I'm sure many others) one is vastly more obvious and easier to understand.

I still don't really understand what SomeType.self is trying to convey upon first glance

Brandon

···

Sent from my iPad

On Dec 15, 2015, at 11:34 AM, Dennis Lysenko <dennis.s.lysenko@gmail.com> wrote:

+1. Side effects can be eliminated through code migration if a suitable property name is chosen. Perhaps `staticType` to continue in the vein of `dynamicType`?

Main detractor is that creating more keywords isn't necessarily a good thing.

On Tue, Dec 15, 2015 at 11:19 AM Brandon Knope via swift-evolution <swift-evolution@swift.org> wrote:
One area of swift that is really not clear to me is when you want to use the type of a class, struct, enum, etc as a value.

Metatyping is explained here: The Swift Programming Language: Redirect

Example:
let metatype: SomeClass.Type = SomeClass.self

Is there a reason why this isn't SomeClass.type? Everywhere in the document this is explained as returning the type yet it's using a postfix self to access the type.

I propose changing the postfix self to something more obvious like "type"

Going back to the example:
let metatype: SomeClass.Type = SomeClass.type

Several reasons why I think this is better:
1. Postfix self is not obvious as an option as you never see a postfix self anywhere else
2. "self" does not clearly explain that the type is being returned
3. ObjC programmers are familiar with accessing the class type by sending the "class" method to the class type. In this case it needs to work on structs and enums, so a "type" method would make more sense.
4. Instances have a dynamicType method. For consistency, classes, structs, etc., should have a type method

Any other suggestions would be welcome.

Brandon

Sent from my iPad

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

5

Sorry, what I meant is not that they have different values, but that they have different levels of meta:

  1> Int.self
$R0: Int.Type = Int
  2> Int.self.dynamicType
$R1: Int.Type.Type = Int.Type

Jordan

···

On Dec 15, 2015, at 13:19 , Drew Crawford <drew@sealedabstract.com> wrote:

On Dec 15, 2015, at 12:24 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

(Alternately, "SomeType.staticType' not being the same as 'SomeType.dynamicType" seems weird.)

Why?

It is not strange to me at all that two different vars return two different things. The names here seem especially clear--staticType being the type as inferred statically, while dynamicType being the runtime type.

+1 for staticType

6

Why?

It is not strange to me at all that two different vars return two different things. The names here seem especially clear--staticType being the type as inferred statically, while dynamicType being the runtime type.

+1 for staticType

···

On Dec 15, 2015, at 12:24 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:

(Alternately, "SomeType.staticType' not being the same as 'SomeType.dynamicType" seems weird.)

7

I also wholeheartedly agree. I've always been a bit confused by that keyword in that context.

···

Sent from my iPhone

On 15 Dec 2015, at 17:42, Brandon Knope via swift-evolution <swift-evolution@swift.org> wrote:

Doh! staticType is the obvious choice!

I agree that adding more keywords can be bad, but in this case I think the clarity outweighs any downside:

SomeType.staticType
SomeType.self

To me (and I'm sure many others) one is vastly more obvious and easier to understand.

I still don't really understand what SomeType.self is trying to convey upon first glance

Brandon

Sent from my iPad

On Dec 15, 2015, at 11:34 AM, Dennis Lysenko <dennis.s.lysenko@gmail.com> wrote:

+1. Side effects can be eliminated through code migration if a suitable property name is chosen. Perhaps `staticType` to continue in the vein of `dynamicType`?

Main detractor is that creating more keywords isn't necessarily a good thing.

On Tue, Dec 15, 2015 at 11:19 AM Brandon Knope via swift-evolution <swift-evolution@swift.org> wrote:
One area of swift that is really not clear to me is when you want to use the type of a class, struct, enum, etc as a value.

Metatyping is explained here: The Swift Programming Language: Redirect

Example:
let metatype: SomeClass.Type = SomeClass.self

Is there a reason why this isn't SomeClass.type? Everywhere in the document this is explained as returning the type yet it's using a postfix self to access the type.

I propose changing the postfix self to something more obvious like "type"

Going back to the example:
let metatype: SomeClass.Type = SomeClass.type

Several reasons why I think this is better:
1. Postfix self is not obvious as an option as you never see a postfix self anywhere else
2. "self" does not clearly explain that the type is being returned
3. ObjC programmers are familiar with accessing the class type by sending the "class" method to the class type. In this case it needs to work on structs and enums, so a "type" method would make more sense.
4. Instances have a dynamicType method. For consistency, classes, structs, etc., should have a type method

Any other suggestions would be welcome.

Brandon

Sent from my iPad

_______________________________________________
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

8

The word "Type" is also blocked in most cases. So still being able to use
the word "type" is less valuable anyway because you cannot create a nested
type called "Type" and will most likely rename it to something like "Kind".

This is actually very annoying:

struct Attachment {

let type: Type

enum Type {
case Image
case Video
}
}

let attachmentType = Attachment.Type // error: expected member name or
constructor call after type name

···

On Tue, Dec 15, 2015 at 7:24 PM, Jordan Rose via swift-evolution < swift-evolution@swift.org> wrote:

".self" was chosen for a few reasons:

- The obvious choice was ".class", given precedent in Objective-C and
Java, but not all types are classes.
- 'type' is a very common property name, so we have tried very hard to
avoid taking it as a general keyword.
- 'type' also always implies going up a level. "obj.dynamicType" gives you
back the type of 'obj', so wouldn't "SomeClass.type" give you back the
metaclass
<http://sealiesoftware.com/blog/archive/2009/04/14/objc_explain_Classes_and_metaclasses.html&gt;?
(Alternately, "SomeType.staticType' not being the same as
'SomeType.dynamicType" seems weird.)
- 'self' is already a keyword.
- ".self" actually works in Objective-C as well.
- ".self" currently also applies to instances, doing exactly what you
think it does. This is *nearly* useless. In theory you could use it to
unwrap one level of optionality ("doubleOpt?.self") but that doesn't
actually work today.

I read "SomeType.self" as "SomeType itself, rather than an instance of it
(or associated type)".

(And before someone brings it up, we chose not to just allow "SomeType" on
its own because "let x = SomeType" is a likely typo for "let x: SomeType".)

I think coming up with a clearer name is possible here, but there's plenty
to consider. Still, certainly a reasonable thing to bring up.

Best,
Jordan

On Dec 15, 2015, at 8:42 , Brandon Knope via swift-evolution < > swift-evolution@swift.org> wrote:

Doh! staticType is the obvious choice!

I agree that adding more keywords can be bad, but in this case I think the
clarity outweighs any downside:

SomeType.staticType
SomeType.self

To me (and I'm sure many others) one is vastly more obvious and easier to
understand.

I still don't really understand what SomeType.self is trying to convey
upon first glance

Brandon

Sent from my iPad

On Dec 15, 2015, at 11:34 AM, Dennis Lysenko <dennis.s.lysenko@gmail.com> > wrote:

+1. Side effects can be eliminated through code migration if a suitable
property name is chosen. Perhaps `staticType` to continue in the vein of
`dynamicType`?

Main detractor is that creating more keywords isn't necessarily a good
thing.

On Tue, Dec 15, 2015 at 11:19 AM Brandon Knope via swift-evolution < > swift-evolution@swift.org> wrote:

One area of swift that is really not clear to me is when you want to use
the type of a class, struct, enum, etc as a value.

Metatyping is explained here:
The Swift Programming Language: Redirect

Example:

   1. let metatype: SomeClass.Type = SomeClass.self

Is there a reason why this isn't SomeClass.type? Everywhere in the
document this is explained as returning the type yet it's using a postfix
self to access the type.

I propose changing the postfix self to something more obvious like "type"

Going back to the example:

   1. let metatype: SomeClass.Type = SomeClass.type

Several reasons why I think this is better:
1. Postfix self is not obvious as an option as you never see a postfix
self anywhere else
2. "self" does not clearly explain that the type is being returned
3. ObjC programmers are familiar with accessing the class type by sending
the "class" method to the class type. In this case it needs to work on
structs and enums, so a "type" method would make more sense.
4. Instances have a dynamicType method. For consistency, classes,
structs, etc., should have a type method

Any other suggestions would be welcome.

Brandon

Sent from my iPad
_______________________________________________
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

9

I have been sitting on a response to this for a while for a few reasons.
1. I didn’t see much interest generated in proceeding with a proposal
2. I have been trying very *hard* to get “SomeType.self” as “SomeType itself, rather than an instance of it” into my head.

My problem is it still does not seem 100% obvious and looks somewhat awkward at first glance.

I mean it’s obvious when the type name is SomeType so you *know* it’s a type. If the type is Mood and you see Mood.self this doesn’t seem as obvious to me.

There has to be a swifter way to do this, but I am not quite sure I’ve found it yet

Brandon

···

On Dec 15, 2015, at 1:24 PM, Jordan Rose <jordan_rose@apple.com> wrote:

".self" was chosen for a few reasons:

- The obvious choice was ".class", given precedent in Objective-C and Java, but not all types are classes.
- 'type' is a very common property name, so we have tried very hard to avoid taking it as a general keyword.
- 'type' also always implies going up a level. "obj.dynamicType" gives you back the type of 'obj', so wouldn't "SomeClass.type" give you back the metaclass <http://sealiesoftware.com/blog/archive/2009/04/14/objc_explain_Classes_and_metaclasses.html&gt;? (Alternately, "SomeType.staticType' not being the same as 'SomeType.dynamicType" seems weird.)
- 'self' is already a keyword.
- ".self" actually works in Objective-C as well.
- ".self" currently also applies to instances, doing exactly what you think it does. This is nearly useless. In theory you could use it to unwrap one level of optionality ("doubleOpt?.self") but that doesn't actually work today.

I read "SomeType.self" as "SomeType itself, rather than an instance of it (or associated type)".

(And before someone brings it up, we chose not to just allow "SomeType" on its own because "let x = SomeType" is a likely typo for "let x: SomeType".)

I think coming up with a clearer name is possible here, but there's plenty to consider. Still, certainly a reasonable thing to bring up.

Best,
Jordan

On Dec 15, 2015, at 8:42 , Brandon Knope via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Doh! staticType is the obvious choice!

I agree that adding more keywords can be bad, but in this case I think the clarity outweighs any downside:

SomeType.staticType
SomeType.self

To me (and I'm sure many others) one is vastly more obvious and easier to understand.

I still don't really understand what SomeType.self is trying to convey upon first glance

Brandon

Sent from my iPad

On Dec 15, 2015, at 11:34 AM, Dennis Lysenko <dennis.s.lysenko@gmail.com <mailto:dennis.s.lysenko@gmail.com>> wrote:

+1. Side effects can be eliminated through code migration if a suitable property name is chosen. Perhaps `staticType` to continue in the vein of `dynamicType`?

Main detractor is that creating more keywords isn't necessarily a good thing.

On Tue, Dec 15, 2015 at 11:19 AM Brandon Knope via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
One area of swift that is really not clear to me is when you want to use the type of a class, struct, enum, etc as a value.

Metatyping is explained here: The Swift Programming Language: Redirect

Example:
let metatype: SomeClass.Type = SomeClass.self

Is there a reason why this isn't SomeClass.type? Everywhere in the document this is explained as returning the type yet it's using a postfix self to access the type.

I propose changing the postfix self to something more obvious like "type"

Going back to the example:
let metatype: SomeClass.Type = SomeClass.type

Several reasons why I think this is better:
1. Postfix self is not obvious as an option as you never see a postfix self anywhere else
2. "self" does not clearly explain that the type is being returned
3. ObjC programmers are familiar with accessing the class type by sending the "class" method to the class type. In this case it needs to work on structs and enums, so a "type" method would make more sense.
4. Instances have a dynamicType method. For consistency, classes, structs, etc., should have a type method

Any other suggestions would be welcome.

Brandon

Sent from my iPad

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

10

I have two questions:

1. why do we need the postfix self?
2. why is the postfix self sometimes required, and sometimes not? (see sample code below):

  func f1<T>(type: T.Type) { print(type) }
  f1(Int) // Int

  func f2<T>(type: T.Type, extra: Bool) { print(type) }
  f2(Int, extra: true) // Compiler error
  f2(Int.self, extra: true) // Int

Gwendal Roué

···

Le 15 déc. 2015 à 22:29, Marc Knaup via swift-evolution <swift-evolution@swift.org> a écrit :

The word "Type" is also blocked in most cases. So still being able to use the word "type" is less valuable anyway because you cannot create a nested type called "Type" and will most likely rename it to something like "Kind".

This is actually very annoying:

struct Attachment {

  let type: Type

  enum Type {
    case Image
    case Video
  }
}

let attachmentType = Attachment.Type // error: expected member name or constructor call after type name

On Tue, Dec 15, 2015 at 7:24 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
".self" was chosen for a few reasons:

- The obvious choice was ".class", given precedent in Objective-C and Java, but not all types are classes.
- 'type' is a very common property name, so we have tried very hard to avoid taking it as a general keyword.
- 'type' also always implies going up a level. "obj.dynamicType" gives you back the type of 'obj', so wouldn't "SomeClass.type" give you back the metaclass <http://sealiesoftware.com/blog/archive/2009/04/14/objc_explain_Classes_and_metaclasses.html&gt;? (Alternately, "SomeType.staticType' not being the same as 'SomeType.dynamicType" seems weird.)
- 'self' is already a keyword.
- ".self" actually works in Objective-C as well.
- ".self" currently also applies to instances, doing exactly what you think it does. This is nearly useless. In theory you could use it to unwrap one level of optionality ("doubleOpt?.self") but that doesn't actually work today.

I read "SomeType.self" as "SomeType itself, rather than an instance of it (or associated type)".

(And before someone brings it up, we chose not to just allow "SomeType" on its own because "let x = SomeType" is a likely typo for "let x: SomeType".)

I think coming up with a clearer name is possible here, but there's plenty to consider. Still, certainly a reasonable thing to bring up.

Best,
Jordan

On Dec 15, 2015, at 8:42 , Brandon Knope via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Doh! staticType is the obvious choice!

I agree that adding more keywords can be bad, but in this case I think the clarity outweighs any downside:

SomeType.staticType
SomeType.self

To me (and I'm sure many others) one is vastly more obvious and easier to understand.

I still don't really understand what SomeType.self is trying to convey upon first glance

Brandon

Sent from my iPad

On Dec 15, 2015, at 11:34 AM, Dennis Lysenko <dennis.s.lysenko@gmail.com <mailto:dennis.s.lysenko@gmail.com>> wrote:

+1. Side effects can be eliminated through code migration if a suitable property name is chosen. Perhaps `staticType` to continue in the vein of `dynamicType`?

Main detractor is that creating more keywords isn't necessarily a good thing.

On Tue, Dec 15, 2015 at 11:19 AM Brandon Knope via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
One area of swift that is really not clear to me is when you want to use the type of a class, struct, enum, etc as a value.

Metatyping is explained here: The Swift Programming Language: Redirect

Example:
let metatype: SomeClass.Type = SomeClass.self

Is there a reason why this isn't SomeClass.type? Everywhere in the document this is explained as returning the type yet it's using a postfix self to access the type.

I propose changing the postfix self to something more obvious like "type"

Going back to the example:
let metatype: SomeClass.Type = SomeClass.type

Several reasons why I think this is better:
1. Postfix self is not obvious as an option as you never see a postfix self anywhere else
2. "self" does not clearly explain that the type is being returned
3. ObjC programmers are familiar with accessing the class type by sending the "class" method to the class type. In this case it needs to work on structs and enums, so a "type" method would make more sense.
4. Instances have a dynamicType method. For consistency, classes, structs, etc., should have a type method

Any other suggestions would be welcome.

Brandon

Sent from my iPad

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

11

It's intended to be required all the time; the cases where it's not required are a bug. (I think it's just single-argument function calls, but I could be wrong.)

Again, it's intended to allow the compiler to produce better diagnostics for "let x = SomeType" when you really meant "let x: SomeType". I can't think of any other examples where the error messages wouldn't be obvious, but with a declaration the diagnostics may be somewhere unrelated to the issue. (Especially if it's a property.)

Jordan

···

On Dec 17, 2015, at 2:12 , Gwendal Roué <gwendal.roue@gmail.com> wrote:

I have two questions:

1. why do we need the postfix self?
2. why is the postfix self sometimes required, and sometimes not? (see sample code below):

  func f1<T>(type: T.Type) { print(type) }
  f1(Int) // Int

  func f2<T>(type: T.Type, extra: Bool) { print(type) }
  f2(Int, extra: true) // Compiler error
  f2(Int.self, extra: true) // Int

Gwendal Roué

Le 15 déc. 2015 à 22:29, Marc Knaup via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :

The word "Type" is also blocked in most cases. So still being able to use the word "type" is less valuable anyway because you cannot create a nested type called "Type" and will most likely rename it to something like "Kind".

This is actually very annoying:

struct Attachment {

  let type: Type

  enum Type {
    case Image
    case Video
  }
}

let attachmentType = Attachment.Type // error: expected member name or constructor call after type name

On Tue, Dec 15, 2015 at 7:24 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
".self" was chosen for a few reasons:

- The obvious choice was ".class", given precedent in Objective-C and Java, but not all types are classes.
- 'type' is a very common property name, so we have tried very hard to avoid taking it as a general keyword.
- 'type' also always implies going up a level. "obj.dynamicType" gives you back the type of 'obj', so wouldn't "SomeClass.type" give you back the metaclass <http://sealiesoftware.com/blog/archive/2009/04/14/objc_explain_Classes_and_metaclasses.html&gt;? (Alternately, "SomeType.staticType' not being the same as 'SomeType.dynamicType" seems weird.)
- 'self' is already a keyword.
- ".self" actually works in Objective-C as well.
- ".self" currently also applies to instances, doing exactly what you think it does. This is nearly useless. In theory you could use it to unwrap one level of optionality ("doubleOpt?.self") but that doesn't actually work today.

I read "SomeType.self" as "SomeType itself, rather than an instance of it (or associated type)".

(And before someone brings it up, we chose not to just allow "SomeType" on its own because "let x = SomeType" is a likely typo for "let x: SomeType".)

I think coming up with a clearer name is possible here, but there's plenty to consider. Still, certainly a reasonable thing to bring up.

Best,
Jordan

On Dec 15, 2015, at 8:42 , Brandon Knope via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Doh! staticType is the obvious choice!

I agree that adding more keywords can be bad, but in this case I think the clarity outweighs any downside:

SomeType.staticType
SomeType.self

To me (and I'm sure many others) one is vastly more obvious and easier to understand.

I still don't really understand what SomeType.self is trying to convey upon first glance

Brandon

Sent from my iPad

On Dec 15, 2015, at 11:34 AM, Dennis Lysenko <dennis.s.lysenko@gmail.com <mailto:dennis.s.lysenko@gmail.com>> wrote:

+1. Side effects can be eliminated through code migration if a suitable property name is chosen. Perhaps `staticType` to continue in the vein of `dynamicType`?

Main detractor is that creating more keywords isn't necessarily a good thing.

On Tue, Dec 15, 2015 at 11:19 AM Brandon Knope via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
One area of swift that is really not clear to me is when you want to use the type of a class, struct, enum, etc as a value.

Metatyping is explained here: The Swift Programming Language: Redirect

Example:
let metatype: SomeClass.Type = SomeClass.self

Is there a reason why this isn't SomeClass.type? Everywhere in the document this is explained as returning the type yet it's using a postfix self to access the type.

I propose changing the postfix self to something more obvious like "type"

Going back to the example:
let metatype: SomeClass.Type = SomeClass.type

Several reasons why I think this is better:
1. Postfix self is not obvious as an option as you never see a postfix self anywhere else
2. "self" does not clearly explain that the type is being returned
3. ObjC programmers are familiar with accessing the class type by sending the "class" method to the class type. In this case it needs to work on structs and enums, so a "type" method would make more sense.
4. Instances have a dynamicType method. For consistency, classes, structs, etc., should have a type method

Any other suggestions would be welcome.

Brandon

Sent from my iPad

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

12

There's also a syntactic ambiguity with < > being both operators and generic parameter brackets that we resolve by requiring generic parameters in expression context to always be followed by a paren, as in a construction Foo<Bar>(), or by a dot, as in Foo<Bar>.member. C# does the same.

-Joe

···

On Dec 17, 2015, at 9:44 AM, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:

It's intended to be required all the time; the cases where it's not required are a bug. (I think it's just single-argument function calls, but I could be wrong.)

Again, it's intended to allow the compiler to produce better diagnostics for "let x = SomeType" when you really meant "let x: SomeType". I can't think of any other examples where the error messages wouldn't be obvious, but with a declaration the diagnostics may be somewhere unrelated to the issue. (Especially if it's a property.)

13

I also find this aspect of Swift very confusing. I have worked a lot with metatypes (and metaprogramming in general) in Python and R, but I can’t really wrap my head around how this works in Swift.

···

On 17 Dec 2015, at 11:12, Gwendal Roué via swift-evolution <swift-evolution@swift.org> wrote:

I have two questions:

1. why do we need the postfix self?
2. why is the postfix self sometimes required, and sometimes not? (see sample code below):

  func f1<T>(type: T.Type) { print(type) }
  f1(Int) // Int

  func f2<T>(type: T.Type, extra: Bool) { print(type) }
  f2(Int, extra: true) // Compiler error
  f2(Int.self, extra: true) // Int

Gwendal Roué

Le 15 déc. 2015 à 22:29, Marc Knaup via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :

The word "Type" is also blocked in most cases. So still being able to use the word "type" is less valuable anyway because you cannot create a nested type called "Type" and will most likely rename it to something like "Kind".

This is actually very annoying:

struct Attachment {

  let type: Type

  enum Type {
    case Image
    case Video
  }
}

let attachmentType = Attachment.Type // error: expected member name or constructor call after type name

On Tue, Dec 15, 2015 at 7:24 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
".self" was chosen for a few reasons:

- The obvious choice was ".class", given precedent in Objective-C and Java, but not all types are classes.
- 'type' is a very common property name, so we have tried very hard to avoid taking it as a general keyword.
- 'type' also always implies going up a level. "obj.dynamicType" gives you back the type of 'obj', so wouldn't "SomeClass.type" give you back the metaclass <http://sealiesoftware.com/blog/archive/2009/04/14/objc_explain_Classes_and_metaclasses.html&gt;? (Alternately, "SomeType.staticType' not being the same as 'SomeType.dynamicType" seems weird.)
- 'self' is already a keyword.
- ".self" actually works in Objective-C as well.
- ".self" currently also applies to instances, doing exactly what you think it does. This is nearly useless. In theory you could use it to unwrap one level of optionality ("doubleOpt?.self") but that doesn't actually work today.

I read "SomeType.self" as "SomeType itself, rather than an instance of it (or associated type)".

(And before someone brings it up, we chose not to just allow "SomeType" on its own because "let x = SomeType" is a likely typo for "let x: SomeType".)

I think coming up with a clearer name is possible here, but there's plenty to consider. Still, certainly a reasonable thing to bring up.

Best,
Jordan

On Dec 15, 2015, at 8:42 , Brandon Knope via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Doh! staticType is the obvious choice!

I agree that adding more keywords can be bad, but in this case I think the clarity outweighs any downside:

SomeType.staticType
SomeType.self

To me (and I'm sure many others) one is vastly more obvious and easier to understand.

I still don't really understand what SomeType.self is trying to convey upon first glance

Brandon

Sent from my iPad

On Dec 15, 2015, at 11:34 AM, Dennis Lysenko <dennis.s.lysenko@gmail.com <mailto:dennis.s.lysenko@gmail.com>> wrote:

+1. Side effects can be eliminated through code migration if a suitable property name is chosen. Perhaps `staticType` to continue in the vein of `dynamicType`?

Main detractor is that creating more keywords isn't necessarily a good thing.

On Tue, Dec 15, 2015 at 11:19 AM Brandon Knope via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
One area of swift that is really not clear to me is when you want to use the type of a class, struct, enum, etc as a value.

Metatyping is explained here: The Swift Programming Language: Redirect

Example:
let metatype: SomeClass.Type = SomeClass.self

Is there a reason why this isn't SomeClass.type? Everywhere in the document this is explained as returning the type yet it's using a postfix self to access the type.

I propose changing the postfix self to something more obvious like "type"

Going back to the example:
let metatype: SomeClass.Type = SomeClass.type

Several reasons why I think this is better:
1. Postfix self is not obvious as an option as you never see a postfix self anywhere else
2. "self" does not clearly explain that the type is being returned
3. ObjC programmers are familiar with accessing the class type by sending the "class" method to the class type. In this case it needs to work on structs and enums, so a "type" method would make more sense.
4. Instances have a dynamicType method. For consistency, classes, structs, etc., should have a type method

Any other suggestions would be welcome.

Brandon

Sent from my iPad

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

14

(Sorry, I pressed the send button accidentally)

What I wanted to say is that maybe one can have a more transparent system, e.g. typeOf(x) that always returns type of x? For example, typeOf(3) can be Int, type of typeOf(Int) will be the metatype of Int, etc. Similarly, to refer to a type, one should just be able to use the type name. Does anyone know the reason why the system was set up like it is in the first place?

Best,

Taras

···

On 17 Dec 2015, at 13:00, Taras Zakharko <taras.zakharko@uzh.ch> wrote:

I also find this aspect of Swift very confusing. I have worked a lot with metatypes (and metaprogramming in general) in Python and R, but I can’t really wrap my head around how this works in Swift.

On 17 Dec 2015, at 11:12, Gwendal Roué via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I have two questions:

1. why do we need the postfix self?
2. why is the postfix self sometimes required, and sometimes not? (see sample code below):

  func f1<T>(type: T.Type) { print(type) }
  f1(Int) // Int

  func f2<T>(type: T.Type, extra: Bool) { print(type) }
  f2(Int, extra: true) // Compiler error
  f2(Int.self, extra: true) // Int

Gwendal Roué

Le 15 déc. 2015 à 22:29, Marc Knaup via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :

The word "Type" is also blocked in most cases. So still being able to use the word "type" is less valuable anyway because you cannot create a nested type called "Type" and will most likely rename it to something like "Kind".

This is actually very annoying:

struct Attachment {

  let type: Type

  enum Type {
    case Image
    case Video
  }
}

let attachmentType = Attachment.Type // error: expected member name or constructor call after type name

On Tue, Dec 15, 2015 at 7:24 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
".self" was chosen for a few reasons:

- The obvious choice was ".class", given precedent in Objective-C and Java, but not all types are classes.
- 'type' is a very common property name, so we have tried very hard to avoid taking it as a general keyword.
- 'type' also always implies going up a level. "obj.dynamicType" gives you back the type of 'obj', so wouldn't "SomeClass.type" give you back the metaclass <http://sealiesoftware.com/blog/archive/2009/04/14/objc_explain_Classes_and_metaclasses.html&gt;? (Alternately, "SomeType.staticType' not being the same as 'SomeType.dynamicType" seems weird.)
- 'self' is already a keyword.
- ".self" actually works in Objective-C as well.
- ".self" currently also applies to instances, doing exactly what you think it does. This is nearly useless. In theory you could use it to unwrap one level of optionality ("doubleOpt?.self") but that doesn't actually work today.

I read "SomeType.self" as "SomeType itself, rather than an instance of it (or associated type)".

(And before someone brings it up, we chose not to just allow "SomeType" on its own because "let x = SomeType" is a likely typo for "let x: SomeType".)

I think coming up with a clearer name is possible here, but there's plenty to consider. Still, certainly a reasonable thing to bring up.

Best,
Jordan

On Dec 15, 2015, at 8:42 , Brandon Knope via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Doh! staticType is the obvious choice!

I agree that adding more keywords can be bad, but in this case I think the clarity outweighs any downside:

SomeType.staticType
SomeType.self

To me (and I'm sure many others) one is vastly more obvious and easier to understand.

I still don't really understand what SomeType.self is trying to convey upon first glance

Brandon

Sent from my iPad

On Dec 15, 2015, at 11:34 AM, Dennis Lysenko <dennis.s.lysenko@gmail.com <mailto:dennis.s.lysenko@gmail.com>> wrote:

+1. Side effects can be eliminated through code migration if a suitable property name is chosen. Perhaps `staticType` to continue in the vein of `dynamicType`?

Main detractor is that creating more keywords isn't necessarily a good thing.

On Tue, Dec 15, 2015 at 11:19 AM Brandon Knope via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
One area of swift that is really not clear to me is when you want to use the type of a class, struct, enum, etc as a value.

Metatyping is explained here: The Swift Programming Language: Redirect

Example:
let metatype: SomeClass.Type = SomeClass.self

Is there a reason why this isn't SomeClass.type? Everywhere in the document this is explained as returning the type yet it's using a postfix self to access the type.

I propose changing the postfix self to something more obvious like "type"

Going back to the example:
let metatype: SomeClass.Type = SomeClass.type

Several reasons why I think this is better:
1. Postfix self is not obvious as an option as you never see a postfix self anywhere else
2. "self" does not clearly explain that the type is being returned
3. ObjC programmers are familiar with accessing the class type by sending the "class" method to the class type. In this case it needs to work on structs and enums, so a "type" method would make more sense.
4. Instances have a dynamicType method. For consistency, classes, structs, etc., should have a type method

Any other suggestions would be welcome.

Brandon

Sent from my iPad

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

15

We have that; it's ".dynamicType". That's not really related to ".self".

Swift's model is like Objective-C's: if you want to refer to a type as a value, you have to call it out specifically. Objective-C chose "[SomeType class]" for this, but "[SomeType self]" actually works as well.

Jordan

···

On Dec 17, 2015, at 4:03 , Taras Zakharko via swift-evolution <swift-evolution@swift.org> wrote:

(Sorry, I pressed the send button accidentally)

What I wanted to say is that maybe one can have a more transparent system, e.g. typeOf(x) that always returns type of x? For example, typeOf(3) can be Int, type of typeOf(Int) will be the metatype of Int, etc. Similarly, to refer to a type, one should just be able to use the type name. Does anyone know the reason why the system was set up like it is in the first place?

Best,

Taras

On 17 Dec 2015, at 13:00, Taras Zakharko <taras.zakharko@uzh.ch <mailto:taras.zakharko@uzh.ch>> wrote:

I also find this aspect of Swift very confusing. I have worked a lot with metatypes (and metaprogramming in general) in Python and R, but I can’t really wrap my head around how this works in Swift.

On 17 Dec 2015, at 11:12, Gwendal Roué via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I have two questions:

1. why do we need the postfix self?
2. why is the postfix self sometimes required, and sometimes not? (see sample code below):

  func f1<T>(type: T.Type) { print(type) }
  f1(Int) // Int

  func f2<T>(type: T.Type, extra: Bool) { print(type) }
  f2(Int, extra: true) // Compiler error
  f2(Int.self, extra: true) // Int

Gwendal Roué

Le 15 déc. 2015 à 22:29, Marc Knaup via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :

The word "Type" is also blocked in most cases. So still being able to use the word "type" is less valuable anyway because you cannot create a nested type called "Type" and will most likely rename it to something like "Kind".

This is actually very annoying:

struct Attachment {

  let type: Type

  enum Type {
    case Image
    case Video
  }
}

let attachmentType = Attachment.Type // error: expected member name or constructor call after type name

On Tue, Dec 15, 2015 at 7:24 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
".self" was chosen for a few reasons:

- The obvious choice was ".class", given precedent in Objective-C and Java, but not all types are classes.
- 'type' is a very common property name, so we have tried very hard to avoid taking it as a general keyword.
- 'type' also always implies going up a level. "obj.dynamicType" gives you back the type of 'obj', so wouldn't "SomeClass.type" give you back the metaclass <http://sealiesoftware.com/blog/archive/2009/04/14/objc_explain_Classes_and_metaclasses.html&gt;? (Alternately, "SomeType.staticType' not being the same as 'SomeType.dynamicType" seems weird.)
- 'self' is already a keyword.
- ".self" actually works in Objective-C as well.
- ".self" currently also applies to instances, doing exactly what you think it does. This is nearly useless. In theory you could use it to unwrap one level of optionality ("doubleOpt?.self") but that doesn't actually work today.

I read "SomeType.self" as "SomeType itself, rather than an instance of it (or associated type)".

(And before someone brings it up, we chose not to just allow "SomeType" on its own because "let x = SomeType" is a likely typo for "let x: SomeType".)

I think coming up with a clearer name is possible here, but there's plenty to consider. Still, certainly a reasonable thing to bring up.

Best,
Jordan

On Dec 15, 2015, at 8:42 , Brandon Knope via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Doh! staticType is the obvious choice!

I agree that adding more keywords can be bad, but in this case I think the clarity outweighs any downside:

SomeType.staticType
SomeType.self

To me (and I'm sure many others) one is vastly more obvious and easier to understand.

I still don't really understand what SomeType.self is trying to convey upon first glance

Brandon

Sent from my iPad

On Dec 15, 2015, at 11:34 AM, Dennis Lysenko <dennis.s.lysenko@gmail.com <mailto:dennis.s.lysenko@gmail.com>> wrote:

+1. Side effects can be eliminated through code migration if a suitable property name is chosen. Perhaps `staticType` to continue in the vein of `dynamicType`?

Main detractor is that creating more keywords isn't necessarily a good thing.

On Tue, Dec 15, 2015 at 11:19 AM Brandon Knope via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
One area of swift that is really not clear to me is when you want to use the type of a class, struct, enum, etc as a value.

Metatyping is explained here: The Swift Programming Language: Redirect

Example:
let metatype: SomeClass.Type = SomeClass.self

Is there a reason why this isn't SomeClass.type? Everywhere in the document this is explained as returning the type yet it's using a postfix self to access the type.

I propose changing the postfix self to something more obvious like "type"

Going back to the example:
let metatype: SomeClass.Type = SomeClass.type

Several reasons why I think this is better:
1. Postfix self is not obvious as an option as you never see a postfix self anywhere else
2. "self" does not clearly explain that the type is being returned
3. ObjC programmers are familiar with accessing the class type by sending the "class" method to the class type. In this case it needs to work on structs and enums, so a "type" method would make more sense.
4. Instances have a dynamicType method. For consistency, classes, structs, etc., should have a type method

Any other suggestions would be welcome.

Brandon

Sent from my iPad

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

16

Objective-C's `[SomeClass class]` is wrong in a formal sense. `[object class]` returns the object's class, but `[SomeClass class]` does not return the class's class (i.e. its metaclass). `[SomeClass self]` is the formally more consistent one.

···

On Dec 17, 2015, at 9:47 AM, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:

We have that; it's ".dynamicType". That's not really related to ".self".

Swift's model is like Objective-C's: if you want to refer to a type as a value, you have to call it out specifically. Objective-C chose "[SomeType class]" for this, but "[SomeType self]" actually works as well.

--
Greg Parker gparker@apple.com Runtime Wrangler