[swift-evolution] [RFC] #Self
Matthew Johnson
matthew at anandabits.com
Tue May 10 16:49:15 CDT 2016
Sent from my iPad
> On May 10, 2016, at 4:01 PM, Chris Lattner <clattner at apple.com> wrote:
>
> On May 10, 2016, at 12:03 PM, Matthew Johnson <matthew at anandabits.com> wrote:
>>>>
>>>> That's a fair critique. Having a more distinct name will make it clear that the behavior is completely unrelated to Self.
>>>>
>>>> How about #Type or #StaticType?
>>>
>>> Either of those would make more sense to me than using # as a distinguisher for dynamic vs static. This isn’t what we use # for.
>>
>> Another suggestion was StaticSelf. Any opinion on that one? Also, do you think we should just drop the # altogether?
>>
>> If we find a name we can agree on and there is no significant opposition is this a proposal that could make it into Swift 3? I would be willing to write one if that is the case.
>
> I haven’t thought about this in depth and completely misunderstood the proposal before :-)
>
> If I understand, this is simply a shortcut to avoid having to spell out the static type name, most useful when copying/pasting code or when the type name is long. That argues for keeping it short (a knock against StaticSelf). Also, I think it would make sense to drop the #: Self doesn’t have it for example, and that is the closest relative.
Good point about keeping it short. 'Type' seems like the best candidate.
>
> That said, I’m not sure I understand the concrete use-cases. When is this concept important? When is “Self” not good enough?
The only case where there is new functionality is when this is used in a protocol requirement. I gave an example earlier today.
It also provides a shortcut for verbose type names, although that is relatively unimportant.
>
> -Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160510/ea3cce59/attachment.html>
More information about the swift-evolution
mailing list