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>?
(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