[swift-evolution] Changing postfix "self" to something clearer like "type"

[Marc Knaup]

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 at 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 at 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 at 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 at 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:
>> https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Types.html#//apple_ref/doc/uid/TP40014097-CH31-XID_1022
>>
>> 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 at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>  _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151215/72f4e460/attachment.html>