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 <[email protected]> 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 >> <[email protected] <mailto:[email protected]>> 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 <[email protected] >> <mailto:[email protected]>> 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 >>> <[email protected] <mailto:[email protected]>> 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: >>> https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Types.html#//apple_ref/doc/uid/TP40014097-CH31-XID_1022 >>> >>> <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Types.html#//apple_ref/doc/uid/TP40014097-CH31-XID_1022> >>> >>> 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 >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
